Johan Herland <johan@xxxxxxxxxxx> writes: > On Monday 28 May 2007, Linus Torvalds wrote: >> >> On Mon, 28 May 2007, Johan Herland wrote: >> > >> > I still don't see what makes note objects inherently more expensive than >> > commit objects. Except for the refs, of course, but we're getting rid >> > of those (at least replacing them with a more efficient reverse mapping). >> >> It's exactly the refs that I worry about. >> >> Anything that needs to read in all notes at startup is going to be _slow_. >> >> In contrast, commits we read when (and only when) we need them. > > Ok. But the reverse mapping will help with this, won't it? > We'll look up the interesting commits and find their associated > note objects directly. The issue Linus brought up worries me, too. The "efficient reverse mapping" is still handwaving at this stage. What it needs to do is an equivalent to your implementation with "refs/notes/<a dir per commit>/<note>". The "efficient" one might do a flat file that says "notee note" per line sorted by notee, or it might use BDB or sqlite, but the amount of the data and complexity of the look-up is really the same. A handful notes per each commit in the history (I think Linus's "Acked-by after the fact" example a very sensible thing to want from this subsystem). I am not saying that it is impossible to make the set-up cost for the "efficient lookup" almost zero, and to make it lazy and on-demand. The concern above just adds one design constraints to that "efficient reverse mapping" code yet to come. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
