HTML5 Storage – Odd Performance Numbers
I’ve been working on a GWT application that makes use of HTML5 local storage to persist state between loads. The target for right now is the iPad and the two webkit browsers — Chrome and Safari.
I wasn’t all that happy with the speed of the local hash storage, so I decided to test out the db versus hash performance. First off was writing. After coding up a quick benchmark and storing 20,000 key-value pairs in both the hash and a db table, I had some really odd numbers:
- Mobile Webkit (on the iPad): 0.96 seconds for the hash, 1.24 seconds for the database
- Chrome 5.0 (Mac): 18.39 (!!) seconds for the hash, 0.31 seconds for the database
- Safari 5.0 (Mac): 0.05 seconds for the hash, 0.17 seconds for the database
What stands out here is the slow performance of Chrome. I’m going to try and do this in vanilla JavaScript, just to take GWT out of the equation. I hope that’s what it is, otherwise this looks like a Chrome bug.







Anybody who has been to our office knows I am an Android fan. My prediction is that the Android platform will end up with a much, much larger install base than iPhone OS. Originally, I felt this way because you can get a Android phone on every carrier for a lower cost than the iPhone – many of them are now free with a contract. This is good enough, but I have a new insight. The Android OS does a great job of directing your attention to highly important information. As such, its easier for new users to pick up and for busy people to use. How can this be? You should argue that the the Android OS so similar to the iPhone OS. You are right. However, it comes down to usability. The majority of people out there won’t explore their device to find information. They just want the phone to do the work for them. If it doesn’t smack them in the head it might as well not exist. Android has two crucial features that make it a helper more than just a smart phone.