todo.txt

we're using usize all over the place for cases size and index into a page.
this is sad, because a page will never exceed 32 bits, and probably will
not exceed 16 bits.

make pgnum a u64?
same for pgnum but then storage is wasteful,
want to store as a varint, but then space in the page calculations are
more complicated.

varint in a separate crate?  but optimizer can't cross crate boundaries.

core feature:  graveyard

reduce malloc

prefixlen > 255

looks like kvp stuff should probably stay boxed.  both the key and value
always need to be held longer than one iteration, usually until the
end of the leaf, and one key for each leaf gets held longer than that.
which means if the caller provided this as a reference instead of a box,
we would have to make a copy no matter what, and if the caller had to
construct a box anyway, we would have done it twice.

a little worried about the KeyCompare always being built in to Seek.
what about cases that don't use it?

tempted to limit key size.  no overflows for keys.  key is limited by
the page size (minus overhead).  if you need a bigger key, then use a
bigger page size.

currently using trait objects Seek+Write for writing to the db.  the overhead
of dynamic dispatch is negligible compared to the IO, right?  lack of
inline optimization?  verify this.

maybe page manager should own the file (or Seek+Write) as well, and should
have a method called WritePage which the bt code would call?  this might
make it easier later to do things like witholding 16 bytes at the end for
crypto.

what if db goes out of scope with pending segments?

let's not panic (int underflow) when we try to write a segment
but the source iterator provides no pairs

https://github.com/zslayton/lifeguard

stray, block list, etc

automerge?  in a thread?

cleanup bcmp and friends

vbuf reuse write leaves

review lock ordering

keyInLeafs should share code.

same for Value and ValueRef code

wonder:  cargo bench and callgrind quick() are not the same test.
bunch is cross-crate  quick() is not.  quick() is the one that
shows the weird arena_avail calls.  bunch is the one that shows
the perf degradation.

compare_two makes far more difference than Key() and Value()

removing Overflowed from KeyRef doesn't help.  also removing
Result wrapper around KeyRef (with Overflowed removed) doesn't
help.

lto in Cargo.toml doesn't help (and no longer crashes in current
nightly)

FWIW, switching the new multicursor sort algo to compare_two makes
a big difference in perf.  compare_two is still way faster than
KeyRef, and the main difference seems to be in extra work being
done by jemalloc, for whatever reason.  also, I tried changing KeyRef
to be smaller by changing Prefixed to store a ref to the page buffer
and a cur and a len, the latter both as u16, instead of the two
bytes slices before.  this should have changed the size of that
enum case from 32 bytes to 12.  and this made very little difference
in perf, so I never committed it.

interesting to compare differences between the original compare_two
and one that simply gets two KeyRefs and calls KeyRef::cmp.

shouldn't it warn if a function returns Result but it cannot return Err?

want to write lint to disallow tabs

clean up organization of this code into modules

perhaps, when reading stuff from a buffer, instead of using a cur variable,
we should use the Read impl of slice

the benefit of getting a reference to the key or value bytes directly
in the page will be diminished when the bytes are compressed or encrypted.

chg names back to Key and Value?

read bson value without alloc?  but then we need to give references into
the buffer, which might be big.  that's basically read bson value with
only one (big) alloc for the object itself.