You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These are both reported as metrics, and also actively logged if
repeated puts are detected in any number. (It is necessary to do
both, because repeated puts could otherwise end up rounded down to
zero, and I'd in fact like to see if the number is at all nonzero.)
I also wanted to try to make some use of these numbers within the
addAndRemoveKeys function... however, at the moment, that goes over
like a lead balloon. Immediately after the first Set operations,
and before the Flush, there may still be some Put operations! (In
practice, I saw both 0 and 1 in the tests that already call the
addAndRemoveKeys test helper function; just enough variance to make
asserting on it not fly.)
The reason for these Puts-without-Flush is that `modifyValue` does
a `store.Put`... but, only in the path where the KV's array is full
and it creates a new subshard: it then puts the new subshard (and not,
arguably surprisingly, itself). Not sure I entirely grok the high
level reasoning behind this. And these Puts are tad difficult to
predict, short of evaluating the full hamt algorithm itself.
These Puts-without-Flush also explains why the graphs for
BenchmarkFill-blocks-per-entry-vs-scale.svg were so uncorrelated,
as remarked on in the previous commit: the number of blocks generated
is largely affected by how many changes are accumulated before Put
starts to occur; and if things aren't *actually* being buffered up
until Flush is called, then of course we get plenty of Put operations
no matter what. This may indicate a problem: if someone was expecting
batching to really work for garbage avoidance reasons, it... doesn't
look like it really does. (It's possible this hasn't actually been
evident in any of the workflows people are using this hamt for, though;
if the workload is doing various point changes, the effectiveness of
this batching doesn't matter very much.)
The countSize method gains some docs, because in the first writing of
this, I reported these blockstore event stats *after* countSize...
and yeah, oof, that's a measurement error alright. (You'll see many,
many, many duplicate puts if you do things in this order.)
b.Logf("on round N=%d: blockstore stats: %#v\n", b.N, blockstore.stats) // note: must refer to this before doing `n.checkSize`; that function has many effects.
0 commit comments