Re: Time to merge scratch/correct-warning-pos into master, perhaps?

[David Engster <deng@randomsample.de>]

> I seem to have a default setting of 4kHz.  This was enough to get several
> thousand hits in each build ("old" and "new") running the test suite.  As
> I wrote in my post just now to Eli, the results came up contrary to what
> was expected - the "old" build, running the simple EQ spent more time in
> it than the "new" build running the complicated EQ.  Possibly I've made
> some silly mistake in the measurements.

Hi Alan,

Are you comparing builds directly before/after the merge of the
correct-warnings branch? The first thing to check would be if EQ is
actually called the same amount of times in both builds. You can do this
with 'perf' by using user-space probes ('uprobes'). Just as an example,
with './emacs' being your emacs binary,

  perf probe -x ./emacs redisplay

would insert a uprobe at redisplay, and with

  perf record -e probe_emacs:redisplay ./emacs

you can save the events. Just to show how flexible this system is:

  perf stat -e probe_emacs:redisplay -a -I 1000

would continuously show you the number of times redisplay is called each
second.

Anyway, measuring things around ~1% with perf can be quite noisy. For
doing exact timings, you can also insert 'uretprobes' which are called
when a function returns, and then you can calculate how long each call
took from the timestamps. In the above example,

   perf probe -x ./emacs 'redisplay%return'

will insert a return probe for 'redisplay', then use

   perf record -e 'probe_emacs:*' ./emacs

and use 'perf script' to display the timestamps. I don't think there's
something built-in to display durations between uprobe/uretprobe, so a
little bit of coding is needed to calculate that from the output. Of
course, these timings will usually be increased by the probe
instrumentations, but for relative comparisons, they should be fine.

-David