Matthew Wakeling wrote:
> Okay, I don't know quite what's happening here. Tom, perhaps you could
> advise. Running opannotate --source, I get this sort of stuff:
>
> /*
> * Total samples for file :
> ".../postgresql-8.4beta2/src/backend/access/gist/gistget.c"
> *
> * 6880 0.2680
> */
>
> and then:
>
> :static int64
> :gistnext(IndexScanDesc scan, TIDBitmap *tbm)
> 81 0.0032 :{ /* gistnext total: 420087 16.3649 */
> : Page p;
>
>
>
> The gistnext total doesn't seem to correspond to the amount I get by
> adding up all the individual lines in gistnest. Moreover, it is greater
> than the total samples attributed to the whole file, and greater than
> the samples assigned to all the lines where gistnext is called.
there's another alternative for profiling that you might try if you
can't get sensible results out of oprofile - cachegrind (which is part
of the valgrind toolset).
basically it runs the code in an emulated environment, but records every
access (reads/writes/CPU cycles/cache hits/misses/etc). it's *extremely*
good at finding hotspots, even when they are due to 'cache flushing'
behavior in your code (for example, trawling a linked list is touching a
bunch of pages and effectively blowing your CPU cache..)
there's an associated graphical tool called kcachegrind which takes the
dumped output and lets you drill down, even to the source code level
(with cycle count/percentage annotations on the source lines)
all you need to do is compile postgres with debug symbols (full
optimization ON, otherwise you end up reaching the wrong conclusions).
there's an example of running valgrind on postgres here:
http://blog.cleverelephant.ca/2008/08/valgrinding-postgis.html
for cachegrind, you basically need to use 'cachegrind' instead of
'valgrind', and don't disable optimization when you build..