Author Topic: Profiling a library  (Read 8093 times)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Profiling a library
« Reply #15 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...

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Profiling a library
« Reply #16 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)?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Profiling a library
« Reply #17 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...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Profiling a library
« Reply #18 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.




Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Profiling a library
« Reply #19 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)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Profiling a library
« Reply #20 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Profiling a library
« Reply #21 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... 

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Profiling a library
« Reply #22 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.

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Profiling a library
« Reply #23 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.
« Last Edit: September 25, 2018, 01:58:00 pm by tigerbeard »