This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
>Currently, yes.

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.
Refer <>

>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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]