463669 - Performance of large object initialisation in eval() is very slow

Status: VERIFIED INVALID

(Core :: JavaScript Engine, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

The attached constructs a large object initialiser along the lines of "{ key1: { ...}, key2: {...} }" and then runs it through eval() to create an actual object. There are 1000 keys and the keys and values are all long.

In Firefox 3.0.1 and 3.0.4 this takes about 5 seconds to run which might not seem that bad but I'm certain it used to run *much* faster. All the nightly builds I've tried going back to July 08 process this in 100ms or so. IE7 also does it in about 100ms. I can't find any nightlies from before Fx 3 was released but I'm pretty sure they ran this sort of thing in about 100ms aswell.

Why would this be so much slower (factor of 50) in the released builds ?

Where can I get some pre 3.0.1 nightlies to check my statement above ?



Reproducible: Always

Steps to Reproduce:
1. Open the attached, press "Go" and note the timing
2.
3.
Actual Results:  
Released builds take about 5 seconds on my windows PC

Expected Results:  
100ms would be nice - that's what IE and nightlies do it in

Opera 9.52 also runs this in 80ms

Comment 1

[Duncan Loveday]

Attachment: HTML test case

Comment 2

[Simon Bünzli]

Is this on a clean profile? For me Firefox 3.0.3 performs in the same range as IE7.

Comment 3

[Duncan Loveday]

Absolutely right - disabled Firebug and it's working well for me too.

I'll resolve as invalid.

Comment 4

[Tyler Downer [He/Him]]

v. WFM with clean

Comment 5

[John J. Barton]

I'd like to know if this was better with Firebug 1.4a, http://getfirebug.com/releases

Comment 6

[Duncan Loveday]

John, I tried 1.4a1 and my browser is unusable - blank and corrupted tabs, lockups and crashes.

Comment 7

[John J. Barton]

? Does not sound like Firebug to be honest. Firebug can't crash Firefox (except if FF lets it). The only way to corrupt tabs is by enabling User CSS.

Comment 8

[Brian Crowder]

Also doesn't sound related to this bug.

Comment 9

[Tyler Downer [He/Him]]

But if Firebug is disabled, then the system does not crash.
Reporter, can you try in a new profile, then install firebug? It could possibly be interaction with that and another extension.

Comment 10

[Duncan Loveday]

(In reply to comment #8)
> Also doesn't sound related to this bug.

(In reply to comment #9)
> But if Firebug is disabled, then the system does not crash.
> Reporter, can you try in a new profile, then install firebug? It could possibly
> be interaction with that and another extension.

I'll open a separate bug for this and add you guys to the CC.

Keep this one just for comments on performance.

Comment 11

[Duncan Loveday]

JJB I am please to say that using Firebug 1.4a (tracing version) the very considerable performance hit noted in this bug is eliminated completely.

Comment 12

[Duncan Loveday]

...HOWEVER, when I upgraded my default profile from 1.2 to 1.4a I get no improvement at all. Does that mean there's a remnant of 1.2 left behind after installing 1.4a over the top ?

Comment 13

[Duncan Loveday]

(In reply to comment #11)
> JJB I am please to say that using Firebug 1.4a (tracing version) the very
> considerable performance hit noted in this bug is eliminated completely.

=== NO IT'S NOT ===, I had it disabled in the profile where it was going fast. Sorry to be so incompetent. Conclusion: Firefox 1.4a (when enabled) still has just as big a hit as 1.2 for the test case in this bug.

Comment 14

[John J. Barton]

1.4a1 does not have the improvement after all. 1.4a2 should appear Monday.

The test case on this bug report says
eval time=182, nKeys=1000
on my old laptop.  FF3.0.3/Firebug 1.4a2 ish.

Comment 15

[Tyler Downer [He/Him]]

 Bug 463801 is the bug report you mentioned in comment #10, correct? Just will make it block this bug.

Comment 16

[John J. Barton]

As the original post notes, the performance impact on eval affects all versions of Firefox equally. Bug 463801 is about FF 3.0.4 only and consequently is unlikely to be related to this issue. I suggest it not block this bug.

For now Firebug 1.4a2 is the state of the art in eval debugging. We probably cannot do much better on these artificial test cases except perhaps use CRC32 rather than MD5 (no one working on this).  Bug 379410 which I am working on will also help. Between them we may be able to get a factor of 4 improvement, moving from 5000/100 = 50 to say 10.  While 4x seems huge, the eval() work is only a faction of most pages so its not that big in the end. Having 379410 block this bug would make more sense.

Comment 17

[Duncan Loveday]

(In reply to comment #16)
> As the original post notes, the performance impact on eval affects all versions
> of Firefox equally. Bug 463801 is about FF 3.0.4 only and consequently is
> unlikely to be related to this issue. I suggest it not block this bug.

Agree, there's nothing to suggest these two bugs are related. Just that I happened to notice one whilst looking at the other.

> For now Firebug 1.4a2 is the state of the art in eval debugging. We probably
> cannot do much better on these artificial test cases except perhaps use CRC32
> rather than MD5 (no one working on this).  Bug 379410 which I am working on
> will also help. Between them we may be able to get a factor of 4 improvement,
> moving from 5000/100 = 50 to say 10.  While 4x seems huge, the eval() work is
> only a faction of most pages so its not that big in the end. Having 379410
> block this bug would make more sense.

If you are saying you get under 200ms for the test case then that's only a factor of 1.8 times the timing without firebug which is a vast improvement on the current factor of 50. In which case I dont' follow the reference to 4x or 10x.

Note that the test case is not artifical. I have a web app that loads data into javascript in exactly this way by serving up JSON-like structures. That's by far the fastest way I've found to get data from a server into the script environment, beats XML parsing hands down on all the browsers I've tried. I can even load 40M strings in very quick time.

Comment 18

[John J. Barton]

(In reply to comment #17)
> If you are saying you get under 200ms for the test case then that's only a
> factor of 1.8 times the timing without firebug which is a vast improvement on
> the current factor of 50. In which case I dont' follow the reference to 4x or
> 10x.

The best speedup I can imagine for Firebug eval() debugging -- when you set breakpoints in eval() code -- is 4x. So it will still be 10x slower than no debugging. Firebug 1.4a2 will avoid the 10x *when* you are not debugging eval() code.


> Note that the test case is not artifical. I have a web app that loads data ...

Sure, but the total user experience time includes lots of other time-consuming steps. The eval() performance may be the biggest issue, but not the only one.

Comment 19

[Duncan Loveday]

JJB, pleased to finally report there's a huge improvement in this test case with 1.4X.0a4. My results just now were around 90ms with is suspended and around 230ms with it resumed. Earlier versions were taking up to 5 seconds to process the eval as noted before.