[Monotone-devel] nvm.experiment.db-compaction

[Markus Schiltknecht]

Hi Zack,

reading the commit ML, I've taken notice that you propagated to 
nvm.experiment.db-compaction as well. Just some quick notes from my side 
to avoid duplicate work.

I've started to migrate to an internal binary representation of hashes, 
the complete "id" now means "a binary id", and only hexenc<id> should 
contain hex encoded ids. As a quick "make check" tells, this currently 
doesn't quite work, because of intermixed binary and hex 
representations. I'm trying to get rid of those - and already have a 
bigger change pending (lots of added hexenc_{en,de}code calls).

I've been struggling somewhat with the vocab_macros.hh. What I wanted 
was to disallow operator<< for a new type ATOMIC_BINARY, but still allow 
(read: define) it for normal ATOMIC and ATOMIC_NOVERIFY types. However, 
maybe due to the templates generated by ENCODINGs and DECORATEs, somehow 
the compiler doesn't get that. Instead, an operator<< for a binary id 
still compiles fine and only the linking fails, because there's no 
operator<< for 'id's. And what's worse: the linker's error messages 
don't help much, because they are not very detailed.

Anyway, all of that vocab cruft is very hard to grok, IMO.

Ideas?

Regards

Markus


P.S.: I'm really wondering about performance of that thing. You once 
mentioned, that those hashes are stored in hex in revisions and 
manifests - thus we'd often need to hex encode them anyway. While that's 
certainly true, we might save some encoding steps when comparing against 
a newly calculated hash.

Plus, there's the space savings, which might be negligible for single 
revision_ids, but consider ancestry_maps, where we store lots of revids 
in memory...