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

RESOLVED DUPLICATE of bug 536544

Status

()

RESOLVED DUPLICATE of bug 536544
9 years ago
2 years ago

People

(Reporter: joran, Unassigned)

Tracking

({perf, testcase})

1.9.1 Branch
x86
Mac OS X
perf, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

743 bytes, text/html
Details
(Reporter)

Description

9 years ago
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?

Comment 1

9 years ago
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

Comment 3

9 years ago
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

9 years ago
Created attachment 419035 [details]
benchmark

Comment 5

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

Comment 6

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

Comment 7

9 years ago
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

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

Comment 9

9 years ago
Safari is ~3ms on this machine, perfect!!!
And you're testing trunk FF?

Comment 11

9 years ago
>> 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.

Comment 13

9 years ago
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

Updated

9 years ago
Depends on: 537595

Updated

9 years ago
Keywords: perf, testcase

Comment 14

9 years ago
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

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

Comment 16

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

Updated

9 years ago
Attachment #419035 - Attachment is obsolete: true

Comment 17

9 years ago
Created attachment 429754 [details]
testcase

Comment 18

9 years ago
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

9 years ago
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.

Comment 21

8 years ago
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

8 years ago
Bug 536544 (see comment 3) is now fixed. I guess this was a duplicate ?
Yes.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 536544
Flags: wanted1.9.2?
You need to log in before you can comment on or make changes to this bug.