- From: Joran Greef <joran@ronomon.com>
- Date: Mon, 4 Apr 2011 19:28:24 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: public-webapps@w3.org
On 04 Apr 2011, at 6:04 PM, Tab Atkins Jr. wrote: > It's new. Do you think it would be wise then to advocate doing away with SQLite before IndexedDB has had a chance to prove itself? Surely two competing APIs would be the fastest way to bring IndexedDB up to speed? > Ironically, the poor performance is because it's using sqlite as a > backing-store in the current implementation. That's being fixed by > replacing sqlite. Yes I am aware of this. There are some design flaws in IndexedDB. For instance, it does not regard objects as opaque (as would a typical key-value store), which means that creating an index on an existing object store would require deserializing/serializing every object therein. Doing that for 50,000 objects on an iPad would be breathtaking. I have written object stores on top of SQLite and they are already an order of magnitude faster than IndexedDB with a more powerful and memory efficient API to boot. > Kinda the point, in that the power/complexity of SQL confuses a huge > number of develoeprs, who end up coding something which doesn't > actually use the relational model in any significant way, but still > pays the cost of it in syntax. I was not referring to SQL but to the underlying primitives exposed through the SQL interface. For example, set operations on indices, or the ability to index objects with array values.
Received on Monday, 4 April 2011 17:29:00 UTC