Closed Bug 576630 Opened 10 years ago Closed 10 years ago
adding an anonymous function wrapper slows down parse speed by a factor of 30
(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.
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.
Attachment #455769 - Attachment mime type: application/octet-stream → application/zip
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...
bz's numbers are still blocker material, imo
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).
This is a dup. Looking up the bug #.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 501908
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 .
I see lots of PN_FUNC going through (no surprise) but also PN_LIST, etc...
I'm definitely testing on a 32-bit OS. The calling convention difference could matter, yes.
You need to log in before you can comment on or make changes to this bug.