[Top][All Lists]

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

Re: On elisp running native

From: Eric Abrahamsen
Subject: Re: On elisp running native
Date: Fri, 29 Nov 2019 00:20:09 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>> [ I wasn't able to follow all the explanations at
>>>   http://akrl.sdf.org/gccemacs.html, such as the one around "function
>>>   frames", with which I'm not familiar.  Are these like activation
>>>   frames? ]
>> Yes I think we both mean the same.  In this case basically where we store
>> automatic variables and data related to the single activated function.
> OK, thanks.  I think "activation frame" is the standard term (of which
> there can be several on the stack at the same time in case of recursion).
>>> - How did you get there?  I see some "we" in the web page, which makes
>>>   it sound like you weren't completely alone.
>> Sorry for that I'm not much into using 'I'.
> That's OK, but I see you tried to use it as a clever ploy to dodge the
> initial question: how did you get there?
>>> - Have you tried to use the compiler as benchmark (i.e. how much faster
>>>   can Emacs compile (either byte-compile or native-compile)) if the
>>>   compiler code is native-compiled (since it's all using
>>>   lexical-binding already)?
>> I use the compiler native compiled but because of the previous point I
>> think is hard to measure the difference.
> How 'bout measuring the time to byte-compile a given set of files, then:
> first using the byte-compiled compiler and then using the
> native-compiled compiler (where "compiler" here means at least cconv.el,
> byte-opt.el, bytecomp.el, and macroexp.el)?
> BTW, I think developing a good set of Elisp benchmarks is useful
> independently from this, so I'd encourage you to submit your benchmarks
> as a new GNU ELPA package (we could also incorporate it into Emacs
> itself, but I think we'll want to use it to compare performance between
> diverse Emacsen, so a separate package makes more sense).
> Maybe someone from the Gnus side will want to submit more benchmarks
> (such as one that manipulates "sets/ranges or article numbers").

Maybe so!

reply via email to

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