Closed Bug 519907 Opened 13 years ago Closed 12 years ago

window.localStorage.setItem takes 2ms per object or 2s per 1000 objects - too slow


(Core :: DOM: Core & HTML, defect)

1.9.1 Branch
Not set





(Reporter: joran, Unassigned)



(Keywords: perf, testcase)


(1 file, 1 obsolete file)

743 bytes, text/html
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: 3.5.3

window.localStorage.setItem takes 2ms per object or 2s per 1000 objects: window.localStorage.setItem('key', 'value') takes 2ms. Safari 4 does the same thing in 0.0033ms per object.

In other words, setting about 1000 objects to local storage takes about 3.3 milliseconds in Safari 4 and 2 seconds(!) in Firefox 3.5.3. 

Reproducible: Always
Severity: critical → normal
Component: General → Storage
Product: Firefox → Toolkit
QA Contact: general → storage
Version: unspecified → 1.9.1 Branch
Assignee: nobody → honzab.moz
Flags: wanted1.9.2?
I don't see this. setItem takes less than 0.003ms per object for me.

Unless, of course, I have a bunch of other windows triggering on the "storage" event, but this is to be expected.
This is likely highly dependent on disk write speed.
Assignee: honzab.moz → nobody
Component: Storage → DOM
Product: Toolkit → Core
QA Contact: storage → general
very slooooooooow webStorage, 2000 times setItem & getItem test:

Firefox 3.6 beta 5 (Win7x86): 94830ms
Opera 10.5.3172 (Win7x86): 140835ms

Chrome 4: 343ms
Safari 4: 3ms
IE 8: 102ms

Konqueror: (not supported)
Attached file benchmark (obsolete) —
On trunk I get ~2000ms, Chrome 4.x is ~1000ms on this machine.
Olli Pettay: Did you try this benchmark on Win7 x86 ??
No, using OSX atm.

Profiling shows that dispatching storage event takes some time. Perhaps
we don't need to dispatch the event if the value isn't really changed.
I get ~95000ms, Chrome 4.x is ~343ms on this machine (Win7 x86, benchmark from attachment).
Safari is ~3ms on this machine, perfect!!!
And you're testing trunk FF?
>> And you're testing trunk FF?

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b6pre) Gecko/20091225 Namoroka/3.6b6pre

It gets 120000ms (120 seconds).
Getting worse. A disgraceful result. Congratulations!
(In reply to comment #11)
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b6pre) Gecko/20091225
> Namoroka/3.6b6pre
That is not a trunk build.
I have also noticed that this can be slow with a largish amount of data. I assume doing something like = "blahblahblahblah" is the same as calling setItem(). It would be nice if there was an 'onComplete' event you could register a callback with.

this is on linux: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b6pre) Gecko/20091231 Namoroka/3.6b6pre
Depends on: 537595
Keywords: perf, testcase
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6
Benchmark from attachment: 77ms on this machine.
Fixed. Please Close.
Sorry, I get this results only when run benchmark from local disk.
+1, performance is still unacceptable on 3.6, and a long way behind other modern browsers.  I think other browsers must not be synchronous on the disk write, firefox shouldn't be either.  Had to disable localStorage support in firefox on our app, a shame.

Not being able to use my real email address in bugzilla is pretty weak as well. :-(
Attachment #419035 - Attachment is obsolete: true
Attached file testcase
Actual testcase results:

Firefox 3.6: 104906ms
Chrome 4: 384ms
IE 8: 89ms
Opera 10.5.3296: 56ms
Safari 4: 2ms
Konqueror: (not supported)
The latest testcase causes an amazing amount of disk activity on my machine, for over 130 seconds. Speeding this up may be as easy as removing a flush() statement.
I get 2000ms for the latest testcase using trunk FF. Too much, sure, but
not anything like 100000.
This is on slow-ish OSX machine.
tooo slow, it's very bad, Firefox save and load 10 kilobytes as if it 100 megabytes. Only one 10KB-string in one item, why so long time?
FF is the worse browser regarding local storage
Bug 536544 (see comment 3) is now fixed. I guess this was a duplicate ?
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 536544
Flags: wanted1.9.2?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.