Re: Emacs benchmark workload to run and time instead of hunch performance

[Emanuel Berg <embe8573@student.uu.se>]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> I get ~0.028 for emacs -Q and ~0.03 using my init file.

From the Emacs man page:

   -q, --no-init-file
           Do not load an init file.

   --no-site-file
           Do not load the site-wide startup file.

   [...]

   -Q, --quick
           Similar  to  "-q  --no-site-file   --no-splash".
           Also, avoid processing X resources.

So yes, it seems this method is correct: emacs and
'emacs -Q' should be identical if in the emacs case,
there aren't any init, startup, or X resources files.

>> Keep calling it I guess it ends up in a cache
>> because it gets much faster - but the emacs -Q is
>> still faster.
>
> That's not the reason.
>
> Do (elp-instrument-function 'man).  It'll tell you
> that for the single-run case much of the time is
> spent in (man "ls").  The Emacs "man" command works
> by calling the system man command which typesets the
> man page from it's troff source then pipes it to
> Emacs.  The Emacs man command first checks if the man
> page is already open in a buffer, if so it just
> switches to that buffer.  So, on the first interation
> of your benchmark you have the system man program
> performing typesetting, then on each later iteration
> it does nothing.  To make the benchmark fair you have
> to kill the man buffer before each run.

OK. Didn't anyone ever attempt to write a serious
workload that would take into account all things like
that? It is a very basic idea so I would be very
surprised if no one did it before, larger in scope and
correcting such details as the one you mentioned.

> Of course cache effects still make the benchmark
> quicker for repeated runs.  That's partly because of
> the processor's cache, but also because Linux's
> file-system cache will store the man page's source
> file.  (It goes below 0.01 for me).

OK.

> I don't know.  Try dividing you init file into two
> halves.  See if the first half or the second half
> causes the slowdown.  When you've found which half it
> is divide that into halves too, and so on until
> you've found the culprit.

Yes. But I'll hold my breath for a while to find out if
no one did this before. I don't want to do organized
testing with that workload. Also, my
modules-loaded-and-configured Emacs is absolutely not
slow - it is just that 'emacs -Q' seems (and is, as
seen) just a tiny bit snappier.

-- 
underground experts united