如何根据配置文件优化应用程序的性能？
我分析了我的应用程序，发现不是我的函数导致了我看到的延迟，而是 winform 函数。我该如何纠正这个问题？有关说明，请参阅：
这是分析的结果：
I have profiled my application and found out that not my functions are causing the delay I see but the winform functions. How can I correct this? For explanation see this:
And this is the result of the profiling:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您无法解决这个问题。
该框架正在调用
DispatchMessage函数由 Windows API 公开，用于将调用GetMessage函数检索到的消息分派给特定的窗口过程窗户。这里“慢”的部分是Windows 本身。当这成为您的瓶颈时，您的应用程序已得到充分优化，您无能为力。
此外，这些配置文件结果并不一定会告诉您此函数很慢。相反，他们告诉您它被多次调用（“Hit Count”）。这个想法是，被频繁调用的函数是代码中的“热点”，值得花一些额外的时间来优化它们的实现（更划算）。但在这种情况下，该函数会被多次调用，因为 Windows 就是通过它来处理应用程序的消息的。在非托管代码和本机 Windows API 的世界中，消息有点像您在 .NET 代码中使用的事件。由于必须引发事件才能发生任何有趣的事情，因此负责调用或分派这些事件（消息）的函数必然会被多次调用。
You can't fix that.
The framework is calling down to the
DispatchMessagefunction exposed by the Windows API, which is used to dispatch a message retrieved by a call to theGetMessagefunction to the window procedure for a particular window.The "slow" part here is Windows itself. When that becomes your bottleneck, your application is sufficiently optimized, and there's nothing more you can do.
Also, those profile results aren't necessarily telling you that this function is slow. Rather, they're telling you that it gets called a lot ("Hit Count"). The idea is that functions that get called a lot are "hot points" in your code, and it's worth taking some extra time to optimize their implementation (more bang for your buck). In this case, though, that function gets called a lot because it's how Windows processes messages for your app. In the world of unmanaged code and the native Windows API, messages are kind of like the events you use in .NET code. Since an event has to be raised for anything interesting to happen, the function that's responsible for calling or dispatching those events (messages) is bound to get called a lot.
Windows 应用程序通常包含一个顶级循环，在其中等待外部事件（例如鼠标移动/单击和键盘点击）或内部生成的事件。当事件发生时，它会调用适当的处理程序，该处理程序可能会执行少量或大量操作。通常，它会遍历相当广泛和深入的调用树，但如果它很快完成，它就会返回等待。
看起来表现良好的应用程序花费了大部分挂钟时间等待下一个外部事件。
一个看起来表现不佳的应用程序花费了大部分时间来遍历调用树以响应事件。
提高其性能的方法是找到瓶颈并消除它们。瓶颈几乎总是由代码中的调用树中的函数调用组成，您不知道这些函数调用的成本很高。代码中没有的调用树部分是您无能为力的，但如果您可以避免调用它们，您就有机会获得加速。
就像您是一位经理试图查看您的员工是否在浪费时间一样，您可以不经事先通知就顺便过来看看他们在做什么。
在软件中，这就是你可以这样做。
小心那些让您感到困惑的分析器，例如 1) 告诉您例程的“自时间”，2) 告诉您调用一个函数的次数，3) 给您一个巨大但大多不相关的图表或表格，或者 4) 很多有趣但通常不相关的线索，例如缓存未命中和线程切换。
找到瓶颈非常容易，因为如果它们很小，那么它们并不是真正的瓶颈，如果它们很大，那么在它们浪费的时间里，它们就在堆栈上，只是等待您注意到。
以下是有关该主题的更多信息。
Windows apps generally contain a top-level loop where they wait for external events like mouse movements/clicks and keyboard hits, or internally generated events. When an event occurs, it calls the appropriate handler, which may do a little or a lot. Typically it walks a pretty extensive and deep call tree, but if it finishes quickly it just goes back to waiting.
An app that appears to perform well is spending most of the wall-clock time waiting for the next external event.
An app that appears to perform poorly is spending most of it's time walking call trees in response to events.
The way to improve its performance is to locate bottlenecks and remove them. Bottlenecks nearly always consist of function calls in the call tree, in your code, that you didn't know were expensive. Parts of the call tree that are not in your code are things you can't do anything about, but if you can avoid calling them, you have an opportunity to get a speedup.
Just as if you were a manager trying to see if your employees are wasting time, you can just drop in unannounced and see what they are doing.
In software, this is how you can do that.
Be careful of profilers that confuse you with things like 1) telling you "self time" of routines, 2) telling you how many times a function is called, 3) give you a massive but mostly irrelevant graph or table, or 4) lots of interesting but not usually relevant clues, like cache misses and thread switches.
Finding bottlenecks is very easy, because if they are small they are not really bottlenecks, and if they are big, during the time they are wasting, they are on the stack, just waiting for you to notice.
Here's more on that subject.