Re: Try and detect common problems in lexical code

[Clément Pit-Claudel]

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.