576630 - adding an anonymous function wrapper slows down parse speed by a factor of 30

Status: RESOLVED DUPLICATE of bug 501908

(Core :: JavaScript Engine, defect)

Description

[Lex Spoon]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.1 (KHTML, like Gecko) Chrome/6.0.427.0 Safari/534.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100403 Firefox/3.6.3

I support AJAX applications that, as they start up, load a few megabytes of JavaScript code. I have noticed that if I add a function wrapper around that code and then invoke the function, it loads much more slowly than if the code is loaded into the root window.  That is, this loads fast:

   CODE

And this loads slowly:

   (function() { CODE })()

I originally found the problem with real application code. However, an isolated way to replicate the problem is described here:

http://blog.lexspoon.org/2010/06/wrapping-code-is-slow-on-firefox.html


Based on further experimentation, it looks like there is some sort of linked list of scopes that are nested within any given scope. Breaking the code up into a number of smaller wrapper functions makes the problem go away.

It would be very helpful if programmers deploying on Firefox could wrap their code in a function wrapper without fear of hitting very bad performance. It's possible to work around this, but it requires either writing the code in an uglier way or using a compiler to rewrite the JavaScript before deployment.

I don't see how to atttach files to a bug report. If someone can give me a place to send them, or an email address of someone to mail them to, I can send pre-generated files that exhibit the problem. Alternatively, run the script linked above to regenerate the test files.

Reproducible: Always

Steps to Reproduce:
1. Load the code into the root window, and observe that it takes about a second.
2. Load the code in a nested function wrapper, and observe that it takes 30+ seconds.

Actual Results:  
The funnction-wrapper version is an order of magnitude slower.

Expected Results:  
The two versions should be pretty much the same speed.

Comment 1

[David Mandelin [:dmandelin]]

(In reply to comment #0)
> I don't see how to atttach files to a bug report. If someone can give me a
> place to send them, or an email address of someone to mail them to, I can send
> pre-generated files that exhibit the problem.

To attach files, click the "Add an attachment" link on this page. Please add both versions, either in a single attachment or as two separate ones.

Comment 2

[Lex Spoon]

Attachment: HTML files exhibiting the problem

There are two directories: fast and slow. The only difference between them is that "slow" has a wrapper function around the bulk of the code.

The script for generating the files is also included.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Using those files, I see these numbers on Mac:

  Fx3.6.3 fast: 1479
  Fx3.6.3 slow: 4983

m-c numbers are similar (1419 and 4224).

Nothing remotely close to the slowdown described in the blog post linked in comment 0...

Comment 4

[Robert Sayre]

bz's numbers are still blocker material, imo

Comment 5

[Boris Zbarsky [:bzbarsky]]

Shark says that 88% of the time is spent in (not under) UnlinkFunctionBoxes, called from RecycleTree, called from compileScript.  And the per-line blame says that 100% of the time in that function is spent on:

100.0%	100.0%	0x2bc1b4		call     0x002bc120	<_ZL19UnlinkFunctionBoxesP11JSParseNodeP13JSTreeContext>		Recursive function call	

(sorry, no debug symbols in this tree).

Comment 6

[Andreas Gal :gal]

This is a dup. Looking up the bug #.

Comment 8

[Lex Spoon]

FWIW, I just ran it again, and got:

slow: initial load time = 33462
fast: initial load time = 1084

Are you guys perhaps using a 32-bit OS? The machine I tested on is a 64-bit
Linux 2.6.24 .

Comment 9

[Boris Zbarsky [:bzbarsky]]

I see lots of PN_FUNC going through (no surprise) but also PN_LIST, etc...

Comment 10

[Boris Zbarsky [:bzbarsky]]

I'm definitely testing on a 32-bit OS.  The calling convention difference could matter, yes.