This is the mail archive of the
mailing list for the Cygwin project.
Re: Is multithreaded profiling on cygwin possible?
- From: "peter garrone" <pgarrone at linuxmail dot org>
- To: cygwin at cygwin dot com
- Date: Tue, 07 Oct 2003 11:12:57 +0800
- Subject: Re: Is multithreaded profiling on cygwin possible?
Sorry for the delay, or the repeat information, my original reply is lost.
Brian Ford wrote:
>peter garrone wrote:
>>If I profile my multi-threaded application, it appears that only the main
>>thread is profiled.
Actually, I think I was only partially correct.
Time for the main thread is accumulated, but function calls
are counted for all threads. This creates misleading data.
>You can, however, profile other threads one at a time if you use
>the gprof API's manually, called from the thread you want to profile. I
>have done this, but it has been too long for me to give you specific
>instructions. Have a look at profile.c, profile.[ch], gmon.[ch] in the
>cygwin sources to see how its done.
Thanks very much, this advice is a great start.
I didnt see any way in the mcount function (winsup/cygwin/mcount.c)
to specify a particular thread. I did see the possibility of calling
moncontrol(1) to enable time accumulation for a particular thread,
and searching dejanews, noticed that this is a
recognised approach to multithreaded profiling.
>While you're there, it should be fairly trivial to create a patch that
>at least loops through all Cygwin created pthreads in the sampler. I
>don't know if that kind of flat profile is what you wanted, though.
Sometimes per-thread profiling is useful, but a flat profile is what
I want for now. Not so much for optimisation, but porting. If a thread
is taking x% cpu on system 1 and y% cpu on system 2, then per-thread
profiling is useful. If the whole application is running much too slow,
then the flat profile is useful. I havent figured out how to get per-thread
cpu on cygwin yet anyway.
<snipped dll discussion>
You commented that dll code is difficult to profile. Would you kindly
send me a few references to this, or keyword sets, my searching is blank.
I am aware of the "profiling cygwin" information, and assume you mean
extra to this.
>>On linux, it is possible to save and set the virtual timer upon creation
>>of each thread, and thereby get a decent profile.
>>However the virtual timer is unavailable on cygwin, and I would imagine
>>that this approach is incorrect, due to differing thread models.
>I've never profiled on Linux and I don't know anything about the virtual
>timer you are refering to. On Solaris, I get a nice flat profile of all
>threads combined, like the implimentation I suggested above. The same
>shared library concerns exist there, but Solaris is good about providing
>static profile enabled libs.
Sorry, I was incorrect. I meant by saving the profiling timer ITIMER_PROF before
thread creation and resetting after, in the thread, cpu profiling was possible.
>Let me know if you want to discuss patch ideas. I used to have a few, but
>no priority time to work on them. :(
I am afraid that this email is the sum of my current knowledge about cygwin
profiling. But if I find out anything else, I will post it.
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html