better results for esquelito

This commit is contained in:
Joey Hess 2015-02-15 14:12:38 -04:00
parent 2fbbb7fab0
commit 3684e4d551

View file

@ -43,7 +43,7 @@ that I could use instead. But, acid-sate needs to load the whole
DB into memory. In the comments of DB into memory. In the comments of
[[bugs/incremental_fsck_should_not_use_sticky_bit]] I examined several [[bugs/incremental_fsck_should_not_use_sticky_bit]] I examined several
other haskell database-like things, and found them all wanting, except for other haskell database-like things, and found them all wanting, except for
possibly TCache. possibly TCache. (And TCache is backed by persistent/sqlite anyway.)
## case study: persistent with sqllite ## case study: persistent with sqllite
@ -120,15 +120,14 @@ With this, 1000 queries takes 0.406s. Note that persistent is probably not
actually doing a join at the SQL level, so this could be sped up using actually doing a join at the SQL level, so this could be sped up using
eg, esquelito. eg, esquelito.
Update2: Using esquelito to do a join got this down to 0.250s. Update2: Using esquelito to do a join got this down to 0.109s.
See `database` branch for code.
Code: <http://lpaste.net/101141> <http://lpaste.net/101142>
Compare the above with 1000 calls to `associatedFiles`, which is approximately Compare the above with 1000 calls to `associatedFiles`, which is approximately
as fast as just opening and reading 1000 files, so will take well under as fast as just opening and reading 1000 files, so will take well under
0.05s with a **cold** cache. 0.05s with a **cold** cache.
So, we're looking at nearly an order of magnitude slowdown using sqlite and So, we're looking at maybe 50% slowdown using sqlite and
persistent for associated files. OTOH, the normalized schema should persistent for associated files. OTOH, the normalized schema should
perform better when adding an associated file to a key that already has many. perform better when adding an associated file to a key that already has many.