Closed Bug 412373 Opened 14 years ago Closed 11 years ago

String assignment too slow

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla, Unassigned)

Details

(Keywords: perf)

Attachments

(1 file, 1 obsolete file)

1.26 KB, text/html
Details
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.
Attached file Test case (obsolete) —
Keywords: perf
Version: unspecified → Trunk
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.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 120977
(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..
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.
I think our "string reuse" issues are ancient, this doesn't strike me as a regression, but perhaps Brendan will have a better perspective.
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
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Attached file Revised test case
Attachment #297094 - Attachment is obsolete: true
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.
Summary: String assignment 100 times too slow → String assignment too slow
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
Ropes made this fast, current nightly yields 0.001s
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.