unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: Emacs benchmark workload to run and time instead of hunch performance
Date: Wed, 09 Jul 2014 00:58:29 +0200	[thread overview]
Message-ID: <87simbzcdm.fsf@debian.uxu> (raw)
In-Reply-To: 87zjgjyj45.fsf@debian.uxu

Emanuel Berg <embe8573@student.uu.se> 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	other threads:[~2014-07-08 22:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-08  1:10 Emacs benchmark workload to run and time instead of hunch performance Emanuel Berg
     [not found] ` <CAAjq1mfg4LtRxfrZ-dy-4jdZX-YfbVfgm-Hqho+4ODQNga3BBw@mail.gmail.com>
2014-07-08 15:18   ` Emanuel Berg
2014-07-08 22:58     ` Emanuel Berg [this message]
2014-07-08 23:30       ` Emanuel Berg
2014-07-09 11:24         ` Robert Thorpe
     [not found] <mailman.5118.1404905070.1147.help-gnu-emacs@gnu.org>
2014-07-09 17:03 ` Emanuel Berg
2014-07-09 22:37   ` Stefan Monnier
     [not found]   ` <mailman.5153.1404945461.1147.help-gnu-emacs@gnu.org>
2014-07-09 23:16     ` Emanuel Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87simbzcdm.fsf@debian.uxu \
    --to=embe8573@student.uu.se \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).