On 04/26/2013 03:30 PM, Gregory Szorc wrote:
However, before that happens, I'd like some consensus that IndexedDB is
the best solution here. I'd especially like to hear what Performance
thinks: I don't want to start creating a "preferred" storage solution
without their blessing. If they have suggestions for specific ways we
should use IndexedDB (or some other solution) to minimize perf impact,
we should try to enforce these through the preferred/wrapper API.
I'm not on the performance team, but I've done some extensive
investigation into SQLite performance[1] and a lot of thinking about how
to efficiently do disk I/O for various workloads from my work with
mozStorage for Thunderbird's global database.
I would say that the IndexedDB API has a very good API[2] that allows
for very efficient back-end implementations. Our existing
implementation could do a lot of things to go faster, especially on
non-SSDs. But that can be done as an enhancement and does not need to
happen yet. I think LevelDB broadly has the right idea, although
Chrome's IndexedDB implementation has some surprising limitations (no
File Blob storage) that suggests it's not there yet.
The API can indeed be a bit heavy-weight for simple needs; shims over
IndexedDB like gaia's asyncStorage helper are the way to go:
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js
Andrew
1:
http://www.visophyte.org/blog/2010/04/06/performance-annotated-sqlite-explaination-visualizations-using-systemtap/
2: The only enhancement I would like is non-binding hinting of desired
batches so that IndexedDB could pre-fetch data that the consumer knows
it is going to want anyways in order to avoid ping-ponging fetch
requests back and forth to the async thread and the main thread. (Right
now mozGetAll can be used to accomplish similar, if non-transparent and
dangerously foot-gunny results.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
