emacs-devel
[Top][All Lists]
Advanced

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

Re: Preview: portable dumper


From: Ken Raeburn
Subject: Re: Preview: portable dumper
Date: Fri, 2 Dec 2016 12:24:50 -0500

On Dec 2, 2016, at 03:03, Eli Zaretskii <address@hidden> wrote:

>> From: Ken Raeburn <address@hidden>
>> 
>> Regardless of the outcome of this current disagreement and whether big-elc 
>> gets used, I think the lread changes may soon be ready to merge, even if the 
>> performance benefits are less drastic for normal Lisp code.
> 
> I agree in general, but let's discuss this again when you think the
> branch is ready.  I'd like to have the branch reviewed by those who
> are interested (I will certainly do that myself) before we merge.

Certainly.  Some of that code is a bit subtle, and I’d appreciate the review.

> Does the branch include any benchmarks, to compare performance with
> the current code, both for dumped.elc and for normal Lisp code?  If
> not, can they be included/added, perhaps under test/?

Not currently.  My benchmark has usually been along the lines of:

  time ./emacs -nw —eval '(progn (sit-for 0.01) (kill-emacs))’

to initialize everything (including tty display and input checking) and then 
quit, in a consistent fashion from run to run.  After running it several times 
and hopefully seeing fairly consistent numbers after the first invocation or 
two, I estimate the average by eye.  So, yeah, it could be more precise.

Since we’re timing Emacs startup itself, we can’t test it with Lisp helper 
functions invoked once Emacs has started like we would with many other things.  
And it’ll be dependent on system issues, like whether emacs and dumped.elc are 
in the kernel’s page cache or not.  For simplicity I’ve been testing with the 
cache warmed up, because it eliminates the storage system hardware and OS 
read-ahead algorithms and such while I focus on the lread.c code, but in the 
real world those will sometimes be factors too, and should be considered.

I’ll think about scripting this in some way that may be more robust, and maybe 
adding hooks for OS-specific cache flushing and such.

Ken


reply via email to

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