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
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)
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 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
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. :-(
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 536544
You need to log in before you can comment on or make changes to this bug.