On Friday, August 25, 2023 3:14:13 PM CEST Doug Gray wrote:
> Christian,
> Reading and testing the example given here I can see the process.
> https://www.thegeekstuff.com/2012/08/gprof-tutorial/
>
> From your directions to Ebab in 2020 I surmise the command line would be:
>
> CXXFLAGS="-O3 -pg -j4" ./configure && make
You should also add -g to add debug information.
> and execute:
>
> ./src/linuxsampler
>
> I presume -O3 are optimisations,
Correct
> -pg is from the current man page for gprof,
Yeah, but that's only for gprof. It injects extra profiling code directly into
the binary. Other profilers like oprofile AFAICR don't need or use that.
> and -j4 to compile using 4 cores. Is this correct?
Correct, and not important in this case. It just speeds up the compilation.
> (I understand not to strip the executable.)
Correct.
It's been a long time that I used gprof or oprofile, so not sure whether the
situation has improved on gprof's end, but back then (years ago) gprof had the
huge disadvantage that it was only capable to profile on application binary
level only, whereas oprofile profiled from application binary level over
individual system libraries, down to lowest kernel level. So oprofile
delivered a much more complete and accurate picture than gprof.
For instance in this case of this SFZ engine issue, it could also be possible
that the bottle neck is somewhere in libsndfile or any library that libsndfile
calls in turn. gprof would not have revealed performance issues in libsndfile
or any other system lib, as it simply did not count those in.
The gig engine does not use any third-party lib during playback of samples.
The SFZ engine however supports a large number of all kinds of audio files.
That's why the SFZ engine calls libsndfile (also during real-time playback of
samples) to delegate support for all those file formats. And I'm not sure if
libsndfile and all the libs that libsndfile calls are designed to be real-time
safe.
/Christian
|
