use bipf seekKeyCached()

[staltz]

Context: ssbc/jitdb#208

Uses BIPF 1.6.0's seekKeyCached API instead of passing pValue around.

Pending on ssbc/jitdb#209 being merged first.

[staltz]

@arj03 Here's the ssb-db2 PR that combines everything. I didn't have time to run benchmarks today, but wanted to make this available for you already.

[arj03]

I ran the benchmarks and it seems as if caching is not kicking in for some reason. Havn't delved deep into the code to see why:

Only JITDB query:
master: 10.1s
this branch: 15.5s

Both JITDB + level indexes during query:
master: 37.4
this branch: 47.3

[staltz]

You might need a full npm install, so I mean rm -rf node_modules

[arj03]

Still the same. Even tried deleting package-lock before running npm i.

[staltz]

Hmmm, it might just be that this new code is slower 🥲

[arj03]

Well at least we have a good new baseline :) I can see that it is definitely hitting to cache inside bipf, so not exactly sure what is going on.

[staltz]

I ran benchmarks on my side as well, and can confirm that the new code would be slower. See before/after.

See also the heatmap from Chrome. 1.5s just spent on cache.get / cache.set is way too much:

I think the root cause, if I can guess, is that there is too many new Map() going on, since the structure of the cache is WeakMap -> Map -> Map -> number. I don't know how to do this differently, because we can't just use [buffer, start, target] array as the key to the Map, because arrays aren't unique.

I figured that's it's worth documenting why this approach didn't work. But I'll close the PRs. 🥲

Before

query: 39678.767ms

query: 44708.553ms

query: 42647.140ms

After

query: 47966.423ms

query: 47688.483ms

query: 48343.490ms

[arj03]

Yeah, good benchmarks. The multiple dictionaries would also have been my guess.