On Mon, 28 May 2007, Shawn O. Pearce wrote: > > What if we use a "slow" storage by "refs/notes/$objname/$notename", This _really_ won't scale. Even if the notes don't exist, just doing the lookup (which will fail for most commits) will be horribly slow, and will populate the dentry cache with negative entries. To get good filesystem performance, you have to - have reasonable hit-rates (and looking it up for each commit is _not_ going to do that) - not have millions of objects. So you'd have to have a separate database. You could do it with a separate index file (or mixing it up with the "index v4" and doing it with a single index file that also contains normal objects), but the point is, it's going to be a real separate database. The current "decorations" approach is actually much more efficient with packed refs (dense in the filesystem), and probably not very bad at all for a smallish set (ie a few hundred to a few thousand) objects, but just reading all the decorations ends up being an overhead at some point. Linus - 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
