GNU bug report logs - #15294
24.3.50; js2-mode parser is several times slower in lexical-binding mode

Previous Next

Full log

Message #33 received at 15294 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15294 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: RE: bug#15294: 24.3.50; js2-mode parser is several times slower in
 lexical-binding mode
Date: Thu, 12 Sep 2013 22:45:21 -0700 (PDT)

> > Or is the byte compiler likely to be improved in this regard, so users
> > need not be aware of it and take measures manually?
> 
> As indicated in the FIXMEs I added in src/bytecode.c at the time, the
> current byte codes for unwind-protect, condition-case, and catch are
> very inefficient for lexical-binding code.
> 
> I do hope to fix those issues by introducing other byte-codes which will
> let us generate significantly more efficient code for those constructs,
> but in 24.1, the priority was to get lexical-binding to work correctly,
> performance being a secondary concern (tho for most idiomatic Elisp
> code, the performance tends to be competitive).
> 
> What people should know is that
> 
>    (let (x y z)
>      ...(setq x ...)
>      ...(setq z ...)
>      ...(setq y ...)
> 
> is often a bad idea in Elisp, and even more so in lexical-binding code
> (in some cases, if a variable is immutable it can be handled
> significantly more efficiently, so the mere existence of a single `setq'
> on a variable can sometimes slow other chunks of code: in many cases
> `let' is cheaper than `setq').

Thank you for both answers.  Will the second apply even after making the
byte-compiler improvements described for the first?  (I'm guessing yes.)
If so, you might want to mention this guideline in the manual.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.