如何基于配置文件优化应用程序的性能？

Question

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:

Answer 1

You can't fix that.

The framework is calling down to the DispatchMessage function exposed by the Windows API, which is used to dispatch a message retrieved by a call to the GetMessage function 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.

Answer 2

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.