412373 - String assignment too slow

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Neil Fraser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 

The attached code in the demo (when unwrapped) is just:
 var oneString;
 oneString = "100kb string...";
 oneString = "Another 100kb string...";
 oneString = "Yet Another 100kb string...";

Doing this 1000 times takes 10 seconds in Firefox 2 and 3a.  IE 6, 7, Opera 9, Safari 3 and Firefox 1 all take well under a second.

My first suspect is that this is a garbage collection issue since if
one does the above assignment more than a few thousand times the
execution speed goes geometric.

Reproducible: Always

Steps to Reproduce:
1. Load attached file.
2. Press 'calculate' button.
Actual Results:  
Observe 10 second execution time.

Expected Results:  
Other browsers execute this two orders of magnitude faster.

Comment 1

[Neil Fraser]

Attachment: Test case

Comment 2

[Brian Crowder]

This is essentially a dupe of a couple of other bugs already in the database.  Interestingly, though, I don't get anything like the poor performance mentioned here, running a minefield nightly from a week or so ago.  The test runs in approximately one second for me.

Comment 3

[Mike Schroepfer]

(In reply to comment #2)
> This is essentially a dupe of a couple of other bugs already in the database. 
> Interestingly, though, I don't get anything like the poor performance mentioned
> here, running a minefield nightly from a week or so ago.  The test runs in
> approximately one second for me.
> 
> *** This bug has been marked as a duplicate of bug 120977 ***
> 

I get .094s on Safari
.126s on IE7
1.4s on Today's trunk.

so 10x slower..

Comment 4

[Jesse Ruderman]

The reporter said it was a regression from Firefox 1, so I don't think it makes sense for this to be marked as a dup of a bug that old.

Comment 5

[Brian Crowder]

I think our "string reuse" issues are ancient, this doesn't strike me as a regression, but perhaps Brendan will have a better perspective.

Comment 6

[Brendan Eich [:brendan]]

Someone should reproduce the regression from Firefox 1 to 2 or 3, and failing that and more data from the reporter, then we can throw this into a dup bin. But prima facie claims here deserve to be tested more, or the reporter helped to find what addon or other change may be hamstringing his testing.

/be

Comment 7

[Neil Fraser]

Attachment: Revised test case

Comment 8

[Neil Fraser]

Thanks for your comments.  It turns out (big surprise) that the situation was much more complicated.  The earlier 100x timings were real, but were the sum of problems originating from many different sources.  In the interests of repeatability and simplicity, I'm recasting this bug to just consider totally clean browsers with no history.

Attached is a new test.  This one is designed to be executed on a freshly-opened browser with zero extensions.

Safari 3:    0.781s
IE 6:        1.031s
IE 7:        1.109s
Opera 9:     6.969s
Firefox 1.0: 6.109s
Firefox 2:   11.813s
Firefox 3b2: 6.007s

The above is for Windows XP.  On Linux the timings are similar, except Firefox 2 is 18 seconds.

Comment 9

[Carlos Alén Silva]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4
XP SP3, freshly-opened Fx, Safe mode:
-Time: 9.714s

ChromePlus 1.3.8.2, based on Chromium 5.0.356.2
-Time: 0.001s (!)

Opera 10.51 Build 3315
-Time: 17.546s

Comment 10

[Tom S [:evilpie]]

Ropes made this fast, current nightly yields 0.001s