On 4/26/2013 1:17 PM, Gregory Szorc wrote:
I'd like to start a discussion about the state of storage in Gecko.
Currently when you are writing a feature that needs to store data, you
have roughly 3 choices:
1) Preferences
2) SQLite
3) Manual file I/O
One of the ongoing tasks I dabbled in was replacing the message folder
cache in Thunderbird with a sane database backend (bug 418551). It's
currently implemented in mork, but it has a very simple database
structure, basically a map of folder URLs -> property name -> string or
integer. It's also a potential hot path in startup, so I actually took
the time to run it through some tests, using traces of actual execution
for my profile to benchmark. When I first compared SQLite to mork, I
never got satisfactory results, so I didn't try, but a LevelDB
implementation (it was the hotness when I decided to run a test) was
whooped soundly by mork--factor of 8 or so. It's really telling that
LevelDB -O3 was even beaten by a mork -O0 (factor of 2). I didn't try
IndexedDB because the API to access the cache in Thunderbird is
inherently synchronous [1] and it's much more pain than it's worth to make
I've come to the conclusion that any database-y solution for a
comparatively small key-value or key-key-value store (my test is
basically a 900 x 10 key store, with around 9000 calls to get/set) is a
performance nightmare. This is the sort of thing that basically needs to
be prefetched into memory and stay resident there forever. I haven't
profiled Taras's suggestion of just using a JSON written atomically (the
synchronous API notwithstanding, it's probably safe to allow for async
write attempts); since I have all the test data and scripts still
around, I might just try that.
[1] From the point of view of consumers, the API boils down to "get this
value [to immediately display in the UI]" and "set this value". Since
mork is pretty much a giant hashtable in memory, it has very fast access
and making everything go async would both greatly increase complexity
and probably also slow down a lot of code.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
