[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] unhexification of revision hashes
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] unhexification of revision hashes |
Date: |
Mon, 28 Jan 2008 16:33:02 -0500 |
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