Timeline for Beyond Stack Sampling: C++ Profilers
Current License: CC BY-SA 2.5
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 5, 2011 at 13:57 | comment | added | Mike Dunlavey | @Michael Burr: Thanks for the tip! I'll look into it. | |
| Jan 5, 2011 at 6:09 | comment | added | Michael Burr | This comment will get buried, since there are so many, but for this type of profiling, on Windows, the cdb debugger would work great - you can tell it to dump all the thread stacks with one command (that's easily repeated), and there's no need to copy/paste each time - just set it up to copy its console output to a log file. | |
| Dec 16, 2010 at 13:45 | comment | added | Mike Dunlavey | @Jake: glad you got it figured out. | |
| Dec 16, 2010 at 4:42 | comment | added | Jake Kurzer | Interestingly, it turned out to basically be a profiling problem in the end. And random pausing was, as always, useful. It wasn't enough on its own, not by a wide margin, but it was useful. | |
| Dec 13, 2010 at 22:02 | comment | added | Mike Dunlavey | @Ben: @Jake: I'm afraid I still have the impression that Jake has a reverse-engineering problem, not a profiling problem. Even if he knew method or line-level timings, counts, percentages, etc., it would still be incomprehensible. Once I wrote a reverse-engineering tool for Cobol apps, that could help figure out what it was doing. (It never saw daylight.) Basically, what it would do is take the source code and boil it down, keeping track of variables & their cases, expanding calls, stuff like that, and let user make notes. | |
| Dec 10, 2010 at 19:55 | comment | added | Jake Kurzer | It's definitely true. I routinely take a walk to the post office. It's rather lovely. Incidentally, if you know the area, you now know where I work. :) | |
| Dec 10, 2010 at 19:53 | comment | added | Mike Dunlavey | @Jake: At least you're in a nice place to go outside and maybe forget the pile of goo for a while. | |
| Dec 10, 2010 at 19:30 | comment | added | Jake Kurzer | I'm not sure that point is perfectly defensible. Some DSLs have a much more limited capacity for havoc by their very nature. An interesting thing to think about. Thanks for all the help, Mike. I'm still holding out for a good profiling mechanism as well, but my optimism has faded to a crumbly husk. | |
| Dec 10, 2010 at 17:10 | comment | added | Mike Dunlavey | @Jake: Not much comfort, but that's the glory of Turing universality. Any language, no matter how high or low level, is equivalent in its unbounded ability to be misused. | |
| Dec 10, 2010 at 16:51 | comment | added | Jake Kurzer | Oh god, trust me, it is exactly as screwy as you think. | |
| Dec 10, 2010 at 3:08 | comment | added | JimR | QT/MFC? Shouldn't that produce mutant children with 3 heads that rock back and forth while calling every idea they hear the stupidest idea ever? Errr... I digress... If you're using any of the MFC Socket classes, immediately rewrite your socket code and then profile. There are ALOT of places in the CSocket code that uses the message loop version of WaitForSingleObject which I've found to kill performance. For the life of me I cannot remember the name of the wait func... :/ | |
| Dec 10, 2010 at 2:48 | comment | added | Ben Voigt | QTMFC integration? Oh great, you've got complicated and evil, and you haven't even gotten to the application-specific code yet. | |
| Dec 10, 2010 at 1:18 | comment | added | Jake Kurzer | I've been doing that, and I think I pinned it down. The QTMFC integration causes there to be at least two event loops at any given point, meaning that time spent in an event loop gets counted twice by most profilers. I'm angry, frustrated, and feeling somewhat betrayed. | |
| Dec 10, 2010 at 0:36 | comment | added | Mike Dunlavey | @Jake: Yeah, there's no profiler gonna be much help on this. I fall back on good old single-stepping through the code as it does certain things, like painting a window or handling a mouse click. After wasting a bunch of time like this, some order rises out of the fog. I wish I could be more help. | |
| Dec 9, 2010 at 23:10 | comment | added | Jake Kurzer | Comments? Comments? THIS IS SPARTA! I... Sorry, don't know where that came from. No, the code makes Klingon Opera look readable, and it's about as well documented. Actually, I think it's far less documented.... Oh god. | |
| Dec 9, 2010 at 22:27 | comment | added | Mike Dunlavey | @Jake: I don't suppose they put any comments in there? When I try to understand somebody else's code, I sorta have to have a general idea what problem they're solving and how. (Even so, it sometimes takes me months to get into it, sadly.) Even so, when you finally see what they're doing, I bet you find it's way overcomplicated. That's my experience. | |
| Dec 9, 2010 at 21:19 | comment | added | Jake Kurzer | The curious part is that I can't really discern why it's spending time in there in the first place. It's a fairly intricate piece of code, even by my sstandards. | |
| Dec 9, 2010 at 20:30 | comment | added | Mike Dunlavey | @Jake: Let me know how it works. As I see it, when I take a pause, the key point is to understand "why am I here", because if the reason is not very good, that's a chance to get some speedup. If you can't find time being spent for poor reasons, you can't get the speedup. | |
| Dec 9, 2010 at 19:35 | comment | added | Jake Kurzer | I've gone ahead and manually instrumented the call backs. :| Stepping hasn't helped that much. :S | |
| Dec 9, 2010 at 19:31 | comment | added | Mike Dunlavey | @Jake: I'm not QT-literate, but there's got to be something that functions as a stacktrace in their weird world. | |
| Dec 9, 2010 at 19:28 | comment | added | Mike Dunlavey | @Jake: Another trick is, when you pause it, then you single-step forward from that point until it "returns", hopefully bringing you back to the code that it came from, and keep doing that until it exits a few layers. Again, they're not making it easy (bless their hearts), but a tough coder should be able to figure the real reason why it's doing what it's doing at the time of the pause. | |
| Dec 9, 2010 at 19:22 | comment | added | Jake Kurzer | I'd rather read hex dumps! :) I've been trying to trace back the stack of QT-hatespew that landed us in this situation, and I was just sort of hoping and praying for a tool to do it, since I expect this won't be the only time I get badgered into this sort of madcap hunt. | |
| Dec 9, 2010 at 19:09 | comment | added | Mike Dunlavey | @Jake: I see, so they're making it difficult to figure out the request-chain that gets you to where you are, by passing messages (hopefully with continuations). That means when you pause, you gotta trace back the imitation stack that they have, in order to figure out the composite reason for doing what its doing. I know that's not simple, but you shouldn't have to do it very much. (I used to read hex dumps. Not fun, but it got the job done.) | |
| Dec 9, 2010 at 18:52 | comment | added | Jake Kurzer | The event loop shows, but not what it is processing. It seems that QT does some pretty quirky stuff in a desperate attempt to pretend to be smalltalk, which is making it difficult to get a finer reading on what's actually costly about the event loop. I hadn't thought of actually using the Breakpoint Blues to my advantage though! :) | |
| Dec 9, 2010 at 18:49 | comment | added | Mike Dunlavey | @Jake: If the event loop is using 80% of time (CPU bound or not), then you should spot it doing that on 80% of pauses, no matter how often or seldom you take them. Or, is it the case that that whole activity does not occur very often, and you're trying to "stab" it? In that case, what I sometimes do is either 1) wrap a loop around the fast code, to "magnify" it, or 2) setup a data-change-breakpoint, and that slows down execution (speeds me up :) by some orders of magnitude. | |
| Dec 9, 2010 at 18:18 | comment | added | Jake Kurzer | I've done all those things, and normally that's been enough in conjunction with AQTime. In fact, it's what led me to my deep suspicions regarding the QT event loop, but now I need to get a better idea of the shape and reason for the 10-15 signals we send every few milliseconds, as well as figure out how exactly the event loop is eating 80% of our time while we're in processor bound tasks. I even scribbled up a couple VS macros to do some of the pausing, but I just can't pause often enough. | |
| Dec 9, 2010 at 16:36 | history | edited | Mike Dunlavey | CC BY-SA 2.5 |
added 196 characters in body
|
| Dec 9, 2010 at 15:13 | history | edited | Mike Dunlavey | CC BY-SA 2.5 |
added 734 characters in body; added 145 characters in body; edited body
|
| Dec 9, 2010 at 14:32 | history | edited | Mike Dunlavey | CC BY-SA 2.5 |
added 1000 characters in body; added 2 characters in body
|
| Dec 9, 2010 at 14:20 | history | answered | Mike Dunlavey | CC BY-SA 2.5 |