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

[Alan Mackenzie]

Hello, David.

On Sat, Feb 19, 2022 at 18:43:34 +0100, David Engster wrote:
> >> Date: Sat, 19 Feb 2022 16:42:07 +0000
> >> Cc: gregory@heytings.org, monnier@iro.umontreal.ca, mattiase@acm.org,
> >>   larsi@gnus.org, emacs-devel@gnu.org
> >> From: Alan Mackenzie <acm@muc.de>

> >> I haven't got any useful information out of the exercise, so far.  I
> >> can't help feeling that I'm missing something.  Is there anything I ought
> >> to be doing that I've not yet done?

> > Maybe you should make EQ real function, with an attribute that would
> > preclude its inlining.

> > I have no other ideas.  Maybe someone else does.

> Making EQ a non-inlined function would be the first step. But since perf
> is a sampling profiler, it is not easy to measure something that's
> already very quick - it's simply quite unlikely that perf would hit it,
> unless it is called extremely often.

It is called extremely often.  I managed to de-inline EQ.

> The default sampling frequency of perf is 1kHz, so the first thing you
> can try is to increase that, so that it becomes more likely to hit EQ
> (see the '-F' switch for 'perf record').

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.

> However, it might simply be that a tracing profiler would be the better
> choice here, so maybe look into good old gprof or valgrind. Or maybe
> even instrument EQ yourself and count cycles between start and end.

Time to sleep on it, I think.  Thanks for the post.

> -David

-- 
Alan Mackenzie (Nuremberg, Germany).