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:
Asked
Active
Viewed 300 times
0
double-beep
- 5,031
- 17
- 33
- 41
Eli Braginskiy
- 2,867
- 5
- 31
- 46
-
What is your program doing overall? Is the UI doing something odd, do you notice slowness when using it? – BrandonAGr Apr 13 '11 at 00:52
2 Answers
2
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.
Cody Gray - on strike
- 239,200
- 50
- 490
- 574
-
i see thanks a lot, anyway however i can make that better? every event is dispatching a message? – Eli Braginskiy Apr 12 '11 at 17:31
-
@Blue Gene: I'd have to see more of your code to give you any more specific hints about optimization. But I seriously doubt that there's anything more you can do. The profile results you're getting are useless—they're telling you that either the .NET Framework's internal code is slow, or Windows itself is slow. Since you didn't write that code, you can't optimize it. No biggie, though, since every other programmer has to work within those same constraints. It's unlikely your app is going to be any slower than theirs. – Cody Gray - on strike Apr 12 '11 at 23:50
1
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.
Community
- 1
- 1
Mike Dunlavey
- 40,059
- 14
- 91
- 135
-
@Mike but the profiler(RedGates Ants) showed that most of the time is spent in the part of the call tree that is not my code-see in the picture. – Eli Braginskiy Apr 12 '11 at 22:04
-
@Blue: I can't seem to get the picture. (It gets into some big download thing.) No matter. When I hear "most of the time is spent in ..." my ears perk up, because that sounds like basic profiler confusion. Self time? Please ignore that - it's useless. Inclusive time? Wall or CPU time? Wall time is what you need. By function or by line? By line is what you need. Hit count - useless. Milliseconds or percent? Percent is what you need. What you're looking for is lines in your code that are on the stack (i.e. active) a high percent of the wall time. Got any of those? – Mike Dunlavey Apr 12 '11 at 22:36
-
This seems like a generic introduction to profile-guided optimization, rather than an answer to the specific question. Maybe that's my fault, given how I rephrased the question's title. The problem here is that the asker wants to know how to optimize API calls made by the framework internally. That's not really possible. – Cody Gray - on strike Apr 12 '11 at 23:49
-
@Cody: Right. He says "found out that not my functions are causing the delay" and "how can i correct this". The key is if a routine's "spending time" that time is also being "spent" by the line that called it, and so on up the stack. For some reason, this seems not to be generally understood. – Mike Dunlavey Apr 12 '11 at 23:59
-
You're right. I didn't realize that wasn't generally understood. And I certainly wasn't saying your answer was wrong. But it's definitely possible that the Framework is making internal calls to `DispatchMessage` by no fault of code written explicitly by the asker. It's part of the internal implementation, not something easily rewritten or optimized. Obviously I agree that he should check the call stack and see what's causing the framework to call that function internally, but it's likely this is a dead end. (Also, I agree with your comments; the profiling software leaves a lot to be desired.) – Cody Gray - on strike Apr 13 '11 at 00:03
-
@Cody: What's hard about systems driven off of internally posted events is that the return pointers just go back to the dispatch loop, and it's difficult to figure out where the posted message came from and why, so for that you gotta be a sleuth. (I think this started in the Apple Mac. Thanks, Steve J., for making our job harder.) – Mike Dunlavey Apr 13 '11 at 00:20