On Jan 28, 2008 4:15 PM, Zbigniew Zagórski <[EMAIL PROTECTED]> 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
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel