Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically

Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically

[Dmitry Gutov]

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?

Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically

[Stefan Monnier]

>> 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

Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically

[Stefan Monnier]

>> 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

Re: trunk r114048: * src/eval.c (Ffuncall): Fix handling of ((lambda ..) ..) in lexically

[Dmitry Gutov]

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).