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

[Robert Thorpe <rt@robertthorpeconsulting.com>]

Emanuel Berg <embe8573@student.uu.se> writes:

> Emanuel Berg <embe8573@student.uu.se> did write:
...
> Not-very-ambitious workload but still:
>
> (defun bench ()
>   (interactive)
>   (define-abbrev global-abbrev-table "rsb" "rec.sport.boxing")
>   (insert "rsb")
>   (expand-abbrev)
>
>   (insert "  3")
>   (backward-char 3)
>   (delete-char 2)
>
>   (buffer-menu)
>
>   (man "ls")
>
>   (beginning-of-buffer) )
>
> (progn
>   (elp-instrument-function 'bench)
>   (bench)
>   (elp-results) )
>
> Execution times for first invocation:
>
> emacs -Q:
>
> bench          1           0.038667778   0.038667778
>
> emacs, with tons of configuration:
>
> bench          1           0.05604648    0.05604648

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

> 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.

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).

> So the next question is just what configs slows it down
> - if there is indeed a difference there...

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.

BR,
Robert Thorpe