[Top][All Lists]

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

Re: Try and detect common problems in lexical code

From: Stefan Monnier
Subject: Re: Try and detect common problems in lexical code
Date: Wed, 18 Mar 2020 20:00:37 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> Another difference is that this probably has a more noticeable
>> performance impact
> Shouldn't the cost be essentially 0 when (defvar) happens "at the toplevel",
> within an empty specdpl stack?  And isn't that the common case (a defvar is
> a toplevel form in a file loaded by a `require')?

specpdl holds all the current dynamic let-bindings, unwind_protects (and
their variants), and the call backtrace info, so it's never really empty
(e.g. `load` itself installs a handful of unwind_protects and
let-bindings on the specpdl stack around the execution of the actual
loaded code).

With the use of lexical binding (especially after byte-compilation), the
specpdl is typically less deep, indeed.  And at the top-level of loading
a file it's usually not terribly deep (unless it's an autoload that
happens in the middle of a deepish recursion).  So there's a chance the cost
won't be significant.

I just wanted to be clear that there is a possibility that the cost can
be above the noise-level in some cases (e.g. files with many defvars
that get (auto)loaded while we're in the middle of a deepish recursion).
I haven't bothered to measure it at all, tho.


reply via email to

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