Mail Archives: cygwin/2003/10/07/12:12:51
peter garrone wrote:
>Brian Ford wrote:
>
>>peter garrone wrote:
>>
>Sorry for the delay, or the repeat information, my original reply is
>lost.
>
No problem.
>>>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.
>
True. I primarily just use PC sampling and not call counts, so I forgot
about that part.
>>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.
>
Well, I might be able to devise a way to count only one thread's calls,
but it would be horrifically slow.
>>PTC
>>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.
>
Flat profiles are usually what I want also. For per thread cpu see:
><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.
>
Points 2 and 4 here are what I was referring to (note that they are
applicable to all DLLs, not just cygwin1.dll).
http://sources.redhat.com/ml/cygwin-patches/2002-q2/msg00206.html
I couldn't seem to dig up any more detail easily.
2.) Paraphrasing, the UNIX profil call (that gprof.c is currently using),
has a contiguous flat address space model. It hashes address samples over
that space into a buffer. The starting and ending address are
automatically pulled from the executable and are in its address space.
DLLs are mapped outside this space non-contiguously.
4.) Paraphrasing, gprof doesn't know how to find and read the symbol
tables from DLLs linked into the executable. I'm not even sure if the
addresses are deterministic.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -