[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs benchmark workload to run and time instead of hunch performanc
Re: Emacs benchmark workload to run and time instead of hunch performance
Wed, 09 Jul 2014 19:03:34 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Robert Thorpe <address@hidden> writes:
> I get ~0.028 for emacs -Q and ~0.03 using my init file.
>From the Emacs man page:
Do not load an init file.
Do not load the site-wide startup file.
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).
> 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
- Re: Emacs benchmark workload to run and time instead of hunch performance,
Emanuel Berg <=