[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: Clément Pit-Claudel
Subject: Re: Try and detect common problems in lexical code
Date: Fri, 20 Mar 2020 12:47:06 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 18/03/2020 20.00, Stefan Monnier wrote:
>>> 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.

Btw, we already do something like this in defvaralias, to make sure that the 
variable being aliased isn't already let-bound.

reply via email to

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