GNAT profiling

GNAT profiling

[Alex R. Mosteo]

Ok, after revising some old threads, I see there was a consensus in that 
(at least linux) gprof doesn't work with multitasking programs, and 
there were reports that it neither does with single-task programs.

I'm thus musing what could be a (preferible free) option for code 
profiling. I've successfully used valgrind for memory profiling, but for 
now I'm DoD with this other aspect.

Any suggestions welcome!

Re: GNAT profiling

[ldb]

Have you looked into oprofile?
http://oprofile.sourceforge.net/news/

Re: GNAT profiling

[Jeffrey Creem]

Alex R. Mosteo wrote:
> Ok, after revising some old threads, I see there was a consensus in that 
> (at least linux) gprof doesn't work with multitasking programs, and 
> there were reports that it neither does with single-task programs.
> 
> I'm thus musing what could be a (preferible free) option for code 
> profiling. I've successfully used valgrind for memory profiling, but for 
> now I'm DoD with this other aspect.
> 
> Any suggestions welcome!

I've certainly used gprof on single threaded programs and it worked fine 
(mostly under Solaris, but still quite a bit under Linux).

One issue has been that for some versions of distribution shipped GCCs 
had pretty broken/bad or incompatible Ada/debug/gprof support.

I know with CentOS 4 things are pretty broken.

Might be interesting to look into oprofile support (might require a 
kernel rebuild).

Re: GNAT profiling

[Alex R. Mosteo]

Jeffrey Creem wrote:
> Alex R. Mosteo wrote:
> 
>> Ok, after revising some old threads, I see there was a consensus in 
>> that (at least linux) gprof doesn't work with multitasking programs, 
>> and there were reports that it neither does with single-task programs.
>>
>> I'm thus musing what could be a (preferible free) option for code 
>> profiling. I've successfully used valgrind for memory profiling, but 
>> for now I'm DoD with this other aspect.
>>
>> Any suggestions welcome!
> 
> 
> I've certainly used gprof on single threaded programs and it worked fine 
> (mostly under Solaris, but still quite a bit under Linux).
> 
> One issue has been that for some versions of distribution shipped GCCs 
> had pretty broken/bad or incompatible Ada/debug/gprof support.
> 
> I know with CentOS 4 things are pretty broken.
> 
> Might be interesting to look into oprofile support (might require a 
> kernel rebuild).

Thanks ldb and Jeffrey for pointing me to this profiler, certainly seems 
very promising and, according to the webpage, doesn't require kernel 
recompilation but just installing a module.

I will post my experience with it after trying.

Re: GNAT profiling

[ldb]

It is my experience that you do not need a kernel rebuild unless you
want profiling information inside the kernel, otherwise it'll just lump
all kernel calls into the same group. In that same vein, you may want
to see if you can get a debug-version of glibc in case you need
profiling information inside of glibc. It depends largely on the
application, but with a "debug kernel" and a debug version of glibc,
you can see exactly what your particular program is calling, or whether
an inordinate amount of time is spent in the system (ie, page faults)
or in libc (ie, memcpy()).

Re: GNAT profiling

[Jean-Pierre Rosen]

Alex R. Mosteo a �crit :
> Ok, after revising some old threads, I see there was a consensus in that 
> (at least linux) gprof doesn't work with multitasking programs, and 
> there were reports that it neither does with single-task programs.
> 
> I'm thus musing what could be a (preferible free) option for code 
> profiling. I've successfully used valgrind for memory profiling, but for 
> now I'm DoD with this other aspect.
> 
> Any suggestions welcome!
Callgrind is an add-on to valgrind for profiling.
I've been quite succesful with it

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr