help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Emanuel Berg
Subject: Re: Emacs benchmark workload to run and time instead of hunch performance
Date: Wed, 09 Jul 2014 00:58:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Emanuel Berg <address@hidden> didn't write:

> https://github.com/jschaf/esup
>
> I suspect this was meant for gnu.emacs.help - OK,
> will check that out.

What I can see from looking a the screenshot and
skimming the README.md this measures Emacs startup
time (esup) - but if you read my post, I said there is
no reason (for me at least) to do that, as I have the
OS automatically start Emacs after booting, so for me
it is part of the boot process. After that I never
close Emacs until I'm done for the time being, closing
Emacs as well as shutting down the computer. And that
is the recommended usage. It can of course be
interesting to measure startup time but for my
practical situation it wouldn't hurt (really) if Emacs
took 10 minutes to start! No, I asked for some
benchmark workload to run that would emulate or to a
degree actually perform what could be considered normal
emaxing - that way, the exact same workload could be
run with and without (emacs -Q) extensive configuration
and the require and load of modules, and then the times
could be compared. In C, there is a way of hammering
the DRAM and the memory bus (both of which might be
shared on a multiprocessor architecture) with memory
accesses that will crash through the core-local caches:
it is called pointer chasing and is basically creating
lots of pointers and then assigning values and
dereferencing the pointers... Pretty simple and
effective. Because Emacs is much more complicated, the
method perhaps must be, too (?); but actually any Elisp
could be executed and timed this way to give some
estimate.

-- 
underground experts united


reply via email to

[Prev in Thread] Current Thread [Next in Thread]