* Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically
[not found] <E1VEkSn-0002Xh-OM@vcs.savannah.gnu.org>
@ 2013-09-06 2:00 ` Dmitry Gutov
2013-09-06 12:18 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Gutov @ 2013-09-06 2:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Hi Stefan,
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> ------------------------------------------------------------
> revno: 114048
> revision-id: monnier@iro.umontreal.ca-20130828182726-uq2hsj7b9v29tk7r
> parent: monnier@iro.umontreal.ca-20130828175712-4bbaymrusge69dpg
> fixes bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11258
This change lowers the performance of the js2-mode parser (which still
uses dynamic scoping, by the way) by the factor of five.
In interpreted mode, when having this file opened:
http://nice-popup.googlecode.com/svn-history/r2/trunk/mootools-core-1.3-full-nocompat.js
Evaluating (js2-time (js2-reparse t))
Shows 0.9s before this revision and some 4.7s after it.
Incidentally, the slowdown factor is similar to I've seen when trying to
measure its performance in lexical-binding mode before this revision.
pre-114048, lexical-binding: t -- 3.95 seconds
114048+, lexical-binding: t -- 7-8 seconds
Should I file a dedicated bug?
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically
2013-09-06 2:00 ` trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically Dmitry Gutov
@ 2013-09-06 12:18 ` Stefan Monnier
2013-09-06 15:11 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2013-09-06 12:18 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
>> revision-id: monnier@iro.umontreal.ca-20130828182726-uq2hsj7b9v29tk7r
>> parent: monnier@iro.umontreal.ca-20130828175712-4bbaymrusge69dpg
>> fixes bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11258
> This change lowers the performance of the js2-mode parser (which still
> uses dynamic scoping, by the way) by the factor of five.
That's very odd. I must be doing something wrong there.
> Incidentally, the slowdown factor is similar to I've seen when trying to
> measure its performance in lexical-binding mode before this revision.
> pre-114048, lexical-binding: t -- 3.95 seconds
> 114048+, lexical-binding: t -- 7-8 seconds
> Should I file a dedicated bug?
Yes.
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically
2013-09-06 12:18 ` Stefan Monnier
@ 2013-09-06 15:11 ` Stefan Monnier
2013-09-06 21:12 ` Dmitry Gutov
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2013-09-06 15:11 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
>> This change lowers the performance of the js2-mode parser (which still
>> uses dynamic scoping, by the way) by the factor of five.
> That's very odd. I must be doing something wrong there.
Indeed, I was calling Ffunction for every function that's not an alias
instead of for every function that's not given as a symbol. I installed
a change which should hopefully fix this. Please confirm that it does.
>> Incidentally, the slowdown factor is similar to I've seen when trying to
>> measure its performance in lexical-binding mode before this revision.
>> pre-114048, lexical-binding: t -- 3.95 seconds
>> 114048+, lexical-binding: t -- 7-8 seconds
>> Should I file a dedicated bug?
Lexical-binding is a bit faster in some cases and a bit slower in
others, so a change is not unheard of, but this large of a change is
unusual (tho I can imagine ways in which that could happen).
I'd be interested in running your test to try and see where the perforce
loss comes from.
BTW, is this with js2-mode compiled or interpreted?
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically
2013-09-06 15:11 ` Stefan Monnier
@ 2013-09-06 21:12 ` Dmitry Gutov
0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Gutov @ 2013-09-06 21:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Indeed, I was calling Ffunction for every function that's not an alias
> instead of for every function that's not given as a symbol. I installed
> a change which should hopefully fix this. Please confirm that it does.
Yep, looks fixed. Thanks!
> I'd be interested in running your test to try and see where the perforce
> loss comes from.
See http://debbugs.gnu.org/15294.
> BTW, is this with js2-mode compiled or interpreted?
The numbers I gave here were for interpreted mode, but in compiled mode
the performance degradation is similar (though the ratio is a bit
smaller).
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-09-06 21:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1VEkSn-0002Xh-OM@vcs.savannah.gnu.org>
2013-09-06 2:00 ` trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically Dmitry Gutov
2013-09-06 12:18 ` Stefan Monnier
2013-09-06 15:11 ` Stefan Monnier
2013-09-06 21:12 ` Dmitry Gutov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).