[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Schiltknecht
Subject: [Monotone-devel] nvm.experiment.db-compaction
Date: Mon, 25 Feb 2008 20:58:10 +0100
User-agent: Mozilla-Thunderbird (X11/20080109)

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.




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...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]