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

Status: RESOLVED DUPLICATE of bug 536544

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

Description

[Joran Greef]

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

Comment 1

[Brian]

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.

Comment 2

[Shawn Wilsher :sdwilsh]

This is likely highly dependent on disk write speed.

Comment 3

[bugzilla33]

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)

Comment 4

[bugzilla33]

Attachment: benchmark

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

On trunk I get ~2000ms, Chrome 4.x is ~1000ms on this machine.

Comment 6

[bugzilla33]

Olli Pettay: Did you try this benchmark on Win7 x86 ??

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 8

[bugzilla33]

I get ~95000ms, Chrome 4.x is ~343ms on this machine (Win7 x86, benchmark from attachment).

Comment 9

[bugzilla33]

Safari is ~3ms on this machine, perfect!!!

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

And you're testing trunk FF?

Comment 11

[bugzilla33]

>> 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!

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

(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.

Comment 13

[David Dahl :ddahl]

I have also noticed that this can be slow with a largish amount of data. I assume doing something like localStorage.foo = "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

Comment 14

[bugzilla33]

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.

Comment 15

[bugzilla33]

Sorry, I get this results only when run benchmark from local disk.

Comment 16

[David Barrett-Kahn]

+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. :-(

Comment 17

[bugzilla33]

Attachment: testcase

Comment 18

[bugzilla33]

Actual testcase results:

Firefox 3.6: 104906ms
Chrome 4: 384ms
IE 8: 89ms
Opera 10.5.3296: 56ms
Safari 4: 2ms
Konqueror: (not supported)

Comment 19

[Brian]

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.

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 21

[holden321]

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

Comment 22

[Jo Hermans]

Bug 536544 (see comment 3) is now fixed. I guess this was a duplicate ?

Comment 23

[Honza Bambas (:mayhemer)]

Yes.