Re: [Monotone-devel] unhexification of revision hashes

[Zack Weinberg]

On Jan 28, 2008 4:15 PM, Zbigniew Zagórski <address@hidden> wrote:
> I don't remember reasons for this change besides db compaction.
> However I see a small a performance hit on windows:
> what                    hex      0.38
> --------------------------------------------
> log --brief          |   46   |  39
> graph                |   2    |  0.8
> ls branches          |  7.7   |  6
> --------------------------------------------
> (seconds, all > dev null, monotone db, nvm head)
>
> Should it be slower? Faster ? Are those test cases feasible ?

I haven't looked at the code yet, but I suspect it is because IDs are
now binary in the database but hexadecimal everywhere else in memory.
Thus, we are converting from binary to hex all over the place, which
hurts.

It *should* be possible to avoid doing that almost everywhere and get
back the speed.  However, the "almost" is important; the textual
representation of revisions, rosters, and changesets has hex IDs in
it. It might be that that alone costs so much performance that we're
hosed.

Markus - how infeasible would it be to change in-memory *_id from hex
to binary before merging this revision?

zw