windows: performance diagnositcs / tuning?
-
i've googled for an hour and can't for the life of me just get an answer to a seemingly simple question:
how do i find out what code is taking so much time when i do a certain thing in my app?
what i'm looking for is the heaviest call stack, known as "sampling", where the analyzer samples the stack say every 1/100th of a second, then collates that into a graph to tell you where the most time was spent.
how do i get this data for my Qt (widgets) app?
-
-
On Windows you can use Visual Studio. It has a good built-in profiler that shows function traces, hot paths, memory consumption and a lot more. Simple introduction: Diagnostic Tools window.
-
I'm not using visual studio, i'm using Qt Creator.
How can i use VS to profile a QtC app?
is there a literally step by step "for dummies" who've never done that before?
-
@davecotter said in windows: performance diagnositcs / tuning?:
I'm not using visual studio, i'm using Qt Creator.
Are you Windows platform, or which? Which compiler toolset? Have you seen page Profiling and Memory Checking Tools in the wiki, I think that's what's on offer?
-
yes, i'm on the Windows platform, win 10 x64. compiler vs2019.
i was expecting some tool that i run side by side with my app, and "attach" it to my running app, hit record, do my action, hit stop, then see the call stacks that are heaviest.
i guess i thought that this might be something that everyone does, so there'd be tools to make it "one click easy" but i guess i assume too much ?
-
Hi,
Even if your main platform is Windows, unless you are doing some highly platform specific stuff, you should consider building your application on Linux and take a shot at KDAB's hotspot as well as heaptrack.
They may find other spots that can require some improvements.
-
umm... i have dozens of dependencies. this is a monumental project, it could take a year or more to port this to linux.
I need to performance tune on Windows, cuz that's where the problem is. i dont have the same problem on mac.
-
Something to add to the roadmap :-)
Then you should check the suggestion form the wiki page linked by @JonB as well as the other tools already suggested here.
One thing to consider as well is checking for a more recent version of Qt to see if there has been some performance related fixes.
-
@davecotter said in windows: performance diagnositcs / tuning?:
compiler vs2019
I used VS toolchain, nothing to do with Qt, that is the simplest to get a profiler. I admit I know nothing about how that would interact with a Qt project and Qt Creator, but is it not possible to use the VS profiler against your C++ code? I don't suppose it's as easy as https://devblogs.microsoft.com/cppblog/bring-your-existing-qt-projects-to-visual-studio/ implies?
-
while i appreciate your taking the time to respond, hearing you suggest i just add linux "to the road map" is like hearing a graphic designer suggest "why don't you just take the tool palette from photoshop and put it in after effects?". The work involved would be monumental, and way way outside the point of what the app is trying to accomplish ;-) i did catch the smiley face, and i'm smiling too, just fyi :)
anyway: this problem occurs ONLY with Qt 6.2 beta 2, so there is no "later version" of Qt to try. no problem with Qt5. and no i can't create a "minimum compile-able example" cuz as i said the app is monumental and i have dozens of subsystems that it relies on that may be at play.
It is not possible to "just build it in VS" again because my app DEPENDS on Qt and the problem happens in the user interface, specifically when browsing menus.
perhaps if i illustrate the problem you may understand better: first i show the app compiled against Qt6, then against Qt5:
https://karaoke.kjams.com/screenshots/slow.mp4i tried the profiling app "Very Sleepy", but that produced mystifying results, showing the vast majority of time being taken up by "not my code":
the first thing that is anywhere near my code is "QFileInfo::filePath", way down the list.-dave
-
@davecotter said in windows: performance diagnositcs / tuning?:
i was expecting some tool that i run side by side with my app, and "attach" it to my running app, hit record, do my action, hit stop, then see the call stacks that are heaviest.
That's exactly how you can use VS for this. It's even easier since you're already using the MSVC compiler, so you'll have all the debug symbols. It doesn't matter what you develop your app in - VS, Qt Creator or notepad. It also doesn't matter if it uses Qt or not.
i guess i thought that this might be something that everyone does
I wouldn't go as far as "everybody", but that's a pretty standard thing, yes.
so there'd be tools to make it "one click easy" but i guess i assume too much ?
Not at all.
Just open VS, Go to Options -> Debugging -> Symbols and add path to where your debug symbols (pdb file) are. If your pdb is right next to the exe (the usual case) you don't need that step.
Then go to Debug -> Performance Profiler, Point it to your executable and hit Start. Your app will start and you can start playing around. Alternatively you can attach VS to already running app by selecting it from the list of processes.
You can set breakpoints and profile the runtime exactly between them or just start/stop recording at any given time and see the profile for that part. -
@Chris-Kawa said in windows: performance diagnositcs / tuning?:
Options -> Debugging -> Symbols and add path to where your debug symbols (pdb file) are, Then go to Debug -> Performance Profiler, Point it to your executable and hit Start
Oh! wow! i had no idea.
That seems like the right direction.
Okay so i did that, and ended up with this:
The selected portion of the timeline is the time i was "browsing the menus".
Unfortunately it doesn't seem all that helpful. I Did point it to the folder of PDBs, but it seems it's either not spending any time in my source code, or is unable to locate my source code.
:(
-
It does show some useful stuff already - you spent 68% of the time on I/O and 22% in the Kernel (not your) code. There are some common causes for this. One common thing when opening dialogs, like file selection dialog, are slow shell extensions that generate file thumbnails. Another problem with slow I/O might be aggressive antivirus software or if you're running under VM some filesystem indirection.
If the top level call comes from Qt you can add Qt pdb locations to the symbols paths.
To see into that "Native" branch you can go to the same symbols settings and check the "Microsoft Symbol Server" option. This will download and load pdbs for the Windows dlls and possibly show a more maningful stack there. Note that it may take a bit more time when starting/attaching to the app as there's usually a ton of small system dlls that are loaded with your app and it will download pdbs for all of them. -
Some additional notes - when the hot path shows only [[Native]] try to expand your range selection to the left. It should then include the calling code and you'll get a better picture.
As for the symbols - If you open the Output window (View->Output) there's gonna be information about symbols loading - what modules are loading and if pdb lookup for them succeeded. Make sure pdbs are found for your exe and Qt's dlls.
And last but not least - If you develop in Qt Creator with something like qmake then the default is not to generate debug information for Release configurations, so you might need to first add some compiler flags in the pro file to generate pdb for your exe.
-
did you see the video of what the performance problem is?
i fail to see how browsing the menu bar could possibly cause IO. maybe kernel stuff but that's doubtful too?
i do not have antivirus except for the built in defender.where are the pdb locations for Qt code? i've added "debug symbols" when i installed the Qt source, but there's another bug on the source possibly not being found.
re: expanding the range: note i press "record", then did the action, then pressed "stop", and made note in the timeline of when it was recording the interesting action. the bracket bookends are OUTSIDE the time i was menu browsing.
note i'm profiling the debug app, not the release app. i know, i shouldn't bother, but the menu browsing is WAY too slow to be normal even for debugging. see the video.
-dave
-
Yes, I've seen the video. The examples I gave were just some I/O related things I've seen in the past. Not saying this is what's happening here. I don't know what causes this.
I'd say your best bet is loading these kernel symbols and seeing if something catches your eye there.
i fail to see how browsing the menu bar could possibly cause IO
Menus and popups are implemented through Windows messages. There's all sorts of stuff going through the system with this and I/O is not just direct opening of files inside of your app. You'd be surprised how an innocent looking message could cause a snowball effect on system calls and quite a lot of seemingly unrelated I/O in various caches, shims and monitoring processes. It might be something as trivial as system logging window events from an injected system dll. Again - not saying this is what happens here. I have no way of knowing. Just pointing out that I/O does not have to be originating directly from your code and does not have to correspond directly to the actions you're performing.
where are the pdb locations for Qt code?
If you added them via installer the pdbs are placed next to the respective dlls inside the Qt installation folder. You will also need to add couple of directories for all the platform, style and whatever other plugins you're using.
but there's another bug on the source possibly not being found.
That's a source mapping for the CDB debugger. It only matters if you want to actually browse Qt source code in Qt Creator. Doesn't matter for callstacks in VS.
note i'm profiling the debug app
Well, not an error in the strict sense, but that's not something you usually do. Debug builds have very different performance, memory and I/O characteristics than the Release ones. One thing to check actually is if the slowness occurs in the Release builds too. Maybe the problem is with the system debug heap that is used in Debug builds.
