Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: tigerbeard on September 22, 2018, 07:58:42 pm

Title: Profiling a library
Post by: tigerbeard on September 22, 2018, 07:58:42 pm
I have a library plugin (DLL) with performance issues. I'd like to profile that, but do not have access to the source of the target application. I can debug it in the target, but I do not know how to use the profiler plugin with a library.

For a executable I set the profiling compiler flag and it reads the executable after execution.

With the lib I comile with the flag and open the profiler plugin and it says
 Error: The target is not executable

Title: Re: Profiling a library
Post by: oBFusCATed on September 22, 2018, 08:59:43 pm
Just use perf and flamegraphs, don't bother with gprof. There is a hotspot UI for perf which is nice...
Title: Re: Profiling a library
Post by: tigerbeard on September 22, 2018, 11:05:12 pm
Thanks great tip. Flame graphs made by that tool are really looking good to quickly get to the beef. I guess perf would fill in for missing stuff like hit counts etc. 
Only one tiny thing I forgot to mention: that libray in question is a windows DLL. Running in a Windows only environment (graphics, so no VM possible)
Title: Re: Profiling a library
Post by: BlueHazzard on September 22, 2018, 11:52:00 pm
Profiling on windows is a pain in the a*** with open source tools... I had some success with "Very Sleepy" http://www.codersnotes.com/sleepy/ I don't know if you can profile dlls with it...
Title: Re: Profiling a library
Post by: tigerbeard on September 23, 2018, 12:32:42 am
From the description is can connect to a live PID, which is good.
Wether it runs with a process which was not compiled for profiling, but is calling a DLL compiled for profiing is to be found out.
Title: Re: Profiling a library
Post by: tigerbeard on September 23, 2018, 06:27:56 pm
Tried to profile the DLL with VerySleepy.  I compiles the DLL with the profile compile switch enabled. in release mode.

The started the Base application from wxSleepy, giving the Apps working directory.
VerySleepy does record stuff while the application runs and after its closed it shows results.
But there are no data except Baseapplcation OS calls and OS module call, nothing specific to the DLL. No link to any function names etc.

So I would conclude you can not use VerySleepy for that purpose
Title: Re: Profiling a library
Post by: BlueHazzard on September 23, 2018, 07:57:36 pm
You have to compile the dll with debug symbols, not with profiler settings enabled. Any profiler needs debug symbols in the binary to give you function names ecc...
Title: Re: Profiling a library
Post by: tigerbeard on September 23, 2018, 11:32:19 pm
Tried that but it made no difference, same result.

Title: Re: Profiling a library
Post by: stahta01 on September 24, 2018, 01:33:39 am
Tried that but it made no difference, same result.

So, you compiled the DLL with debug symbols; but, failed to get more information, correct?

Tim S.
Title: Re: Profiling a library
Post by: tigerbeard on September 24, 2018, 11:08:52 am
Right. I did compile the DLL with -g compiler switch and with/without -pg switch and run its executable with VerySleepy.
I did not see a single list entry with a function from the DLL, even though I could verifiy it was definitely executed.

Did you manage to profile a DLL with VerySleepy before?

Title: Re: Profiling a library
Post by: oBFusCATed on September 24, 2018, 11:26:47 am
The flag for symbols is -g not -G...
Title: Re: Profiling a library
Post by: tigerbeard on September 24, 2018, 11:28:27 am
of course, typo. Corrected it.
Thanks
Title: Re: Profiling a library
Post by: stahta01 on September 24, 2018, 06:12:26 pm
And, you made sure there was no "-s" that strips the debug symbols.

Tim S
Title: Re: Profiling a library
Post by: BlueHazzard on September 24, 2018, 07:08:00 pm
I see this also some times: For example i can not profile the code completion plugin dll of codeblocks. The symbols are simply not found, but i have them activated, because other core plugins and the wxWidgets dll work fine... Just the code completion plugin won't show me any call stack or function names...

I tried to find the reason, but was not successful. If someone is able to do it, please let me know ;)
Title: Re: Profiling a library
Post by: tigerbeard on September 24, 2018, 07:16:28 pm
And, you made sure there was no "-s" that strips the debug symbols.
Yes, also the huge filesize showed that the symbols were is. Optimazion was off as well

other core plugins and the wxWidgets dll work fine...
Do you mean you could profile one (or more) of those non-code-completion-plugins while there were running in  Codeblocks?
Title: Re: Profiling a library
Post by: BlueHazzard on September 24, 2018, 07:39:22 pm
Do you mean you could profile one (or more) of those non-code-completion-plugins while there were running in  Codeblocks?
i checked it again, and plugins all do not work. I get no signature from them, only some Alphanumerical code
Code
ZN8wxBitmap8LoadFileERK8wxString12wxBitmapType	wxmsw30ud_gcc_custom	[unknown]	0	0xc477a55
ZN8wxBitmapC2ERK8wxString12wxBitmapType wxmsw30ud_gcc_custom [unknown] 0 0xc476490
[2E55801D] ThreadSearch 0 0x2e55801d
[2E555791] ThreadSearch 0 0x2e555791
[2E53D18C] ThreadSearch 0 0x2e53d18c
[2E53CFCB] ThreadSearch 0 0x2e53cfcb
ZNK16wxAppConsoleBase11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_ wxmsw30ud_gcc_custom [unknown] 0 0xc324074
ZNK16wxAppConsoleBase16CallEventHandlerEP12wxEvtHandlerR14wxEventFunctorR7wxEvent wxmsw30ud_gcc_custom [unknown] 0 0xc3240d0

The wxWidgets dll works fine as seen from above...
Title: Re: Profiling a library
Post by: tigerbeard on September 24, 2018, 07:53:06 pm
Well, at least it does list the DLL at all. Thats more than it did for my DLL, which was used but never appeared in the VerySleepy List as loaded.

Would you mind posting the actual compile command from the C::B message windows (there would be all switches/Settings etc visible)?
Title: Re: Profiling a library
Post by: oBFusCATed on September 24, 2018, 09:31:10 pm
Are you able to profile even a simple executable with a slow for loop in it? Several function calls to a slow function?
What about profiling a simple exe which calls to a slow dll funciton?

Start simple then make it complex.

p.s. profiling is done with optimisations enabled...
Title: Re: Profiling a library
Post by: tigerbeard on September 24, 2018, 10:28:43 pm
As I said above, I could profile a normal application with not problems with VerySleepy.

In this DLL case I can not start simple, since I do not have sources nor control of the host application and the minimum interface is above a certain complexity already. Otherwise its a good idea of course.

What you suggest would mean to setup a test case with simple Host App and a simple test DLL. As I do not have something close lying around I will not start that, right now. But I agree that this is the most efficient approach to test out that capabiltiy for VerySleepy.

I am leaning from this thread, that it does not seem to be an often used standard use case for VerySleepy.


PS I had tried the optimization on and off, this made no difference.



Title: Re: Profiling a library
Post by: BlueHazzard on September 25, 2018, 12:38:51 am
VerySleepy seems to be abandoned since some time...
If i remember correctly AMD had some quite good profiler for windows. But they terminated it and replaced it with some new Program. I used it, but the UI was terrrible... You could try this AMD tool, or you will have to take some money and buy something.... https://developer.amd.com/amd-uprof/ (don't know if you have an intel cpu, and if this program works with it)
Title: Re: Profiling a library
Post by: oBFusCATed on September 25, 2018, 09:23:16 am
What you suggest would mean to setup a test case with simple Host App and a simple test DLL.
Yes, this is what I suggest, it is a 15 min job or in other words - it would be faster to set it up than typing the post where you've explained how you cannot do it.
Title: Re: Profiling a library
Post by: tigerbeard on September 25, 2018, 11:27:23 am
What you suggest would mean to setup a test case with simple Host App and a simple test DLL.
it is a 15 min job or in other words - it would be faster to set it up than typing the post where you've explained how you cannot do it.

touché.  8). Though I am a veeeeery show typer... 
Title: Re: Profiling a library
Post by: tigerbeard on September 25, 2018, 11:46:24 am
VerySleepy seems to be abandoned since some time...
If i remember correctly AMD had some quite good profiler for windows. But they terminated it and replaced it with some new Program. I used it, but the UI was terrrible... You could try this AMD tool, or you will have to take some money and buy something.... https://developer.amd.com/amd-uprof/ (don't know if you have an intel cpu, and if this program works with it)
It is a polling profiler with support for both AMD/Intel. Versions for Windows and AMD are available. Looks worth a trial.
Title: Re: Profiling a library
Post by: tigerbeard on September 25, 2018, 12:47:18 pm
After testing out the AMD UProf tool I have to say its the best solution so far for 64bit OS (does not work on any 32bit platform).

Its GUI looks & feels like a web page guiding you through the selection of the application, set source and symbold dirs and configure the Profiler. Defaults are ok for basic check.
A good thing is that you can runs the app from the profiler, even select a delay to skip long inits and automatically close the application.
Saving a profile allows it to switch between different applications to test.
The GUI has a good structure with basic use case oriented tabs. I find it very intuitive.

When running the profiler it it starts the application and displays a conuter. After stopping it analyzes the data and in the most minimla case it
 * does show a tree view with the application and
 ** all modules
 ** all threads
 * a lower window with all the functions called by the selected item in the tree
 * shown are different column depending on the setup. In my case it was the CPU timing only.

In my test caas I compiled a DLL with profiling and debug symbold active. I pointed the profiler to the directory with the sources, and as symbold selected the directory where C::B built the target DLL.

The result gave me what VerySleepy did not:
 * All modules of the application were listed by name in the tree
 * each module showed the total CPU time. Easy to compare with the total time of higher order modules or the applicatoni
 ** all system dependencies of each module is listed with timing
 * The application function calls were IDs only (same as VerySleepy)
 * The DLL functions were by name with timing in [ms]. It were wxWidget calls and system calls.
    Example
     wxMBConv::FromWChar(char*, unsigned int, wchar_t cont*, unsigned int) const      0.009
     LeaveCriticalSection                                                                                                 0.003
 
The result showed, that function calls within my DLL were not shown, the "debug symbols" were not generated or stored elsewhere. The doc says it needs *.pdb files in windows. I have not yet figured out to get gcc produce pdb for my own code, but that should not be too difficult to find out.

All in all, great results for a quick and dirty test. Even when this is used only sparingly, its intuitive enough to get useful insights about total timing and where time is spent. By inserting "flag pole" sys calls in certain functions you could even to the analogous to "printf debugging" in profiling with this tool. If you have nothing better this is definitedly a recommendation.

Thanks BlueHazzard for the recommendation.