On 04 Apr 2011, at 7:28 PM, Mikeal Rogers wrote: > the biggest bottleneck here in the current implementation would be the > transaction overhead on a database this size, which is because of performance > problems in sqlite which is underlying the implementation. sqlite can't fix > this, it's currently the problem. the object serialization is not a huge > performance issue, performance issues in databases are almost always do to IO > or transaction locks.
You do not have me convinced. I have tried these things (and was once an avid CouchDB user), and one of the first things I learnt was that object deserialization/serialization incurs a massive performance penalty. Just measure the time it takes to JSON.parse/JSON.stringify 50,000 objects on an iPad and then implement an indexing scheme that avoids this overhead and compare the performance times. > you should most definitely be able build sqlite on top of IDB, there would be > a performance penalty of course, which we can address, but you should be able > to do it. if you can't then we need to extend the specification. Trust me on this Mikeal, you cannot build SQLite on top of IDB, the primitives are simply not there. I have been asking for the specification to be extended (namely with regards to schema-less index operation, set operations on indices, and opaque objects) and one or two of the contributors have expressed interest but Mozilla do not appear to be enthralled. Read up on SQLite if you have not yet had the chance to understand the mammoth collective effort it represents: http://www.sqlite.org (it's a stellar project)
