On Thu, Nov 20, 2008 at 02:12:54PM +0100, Johannes Schindelin wrote: > The same goes on here. I wanted to take Peff's idea -- that hadn't > occurred to me back when I tried to help Johan with his notes idea -- > which is to read in the whole notes tree into a singleton when needed, and > incorporate it into my existing test framework. > > Maybe I'll find time later today. In case you do work on it, let me quickly communicate the two thoughts I have had since the GitTogether (and you can feel free to ignore them, but I want to try to say them before you code something differently, so you at least have the _choice_ of ignoring them. :) ). One is some thoughts on naming, which I already articulated here: http://article.gmane.org/gmane.comp.version-control.git/100402 The other is on speeding up tree lookup. I think the "notes as a git tree" is sound, but as we obviously realized, somewhat slow. So the "speeding up notes" code is really about "speeding up tree lookup". And while it would be nice for pack v4 to fix this for free, I don't think we want to wait for that. And I think the "build a hash on the fly" approach that I posted earlier is a sensible way to go. _But_ where I think we should differ from that patch is that any notes speedup should really be about a generic interface for speeding up tree lookup. That is, it should come in the generic form of: void tree_study(struct tree_study_context *c, struct tree *tree); void tree_study_lookup(struct tree_study_context *c, const char *name); where "tree_study" spends some cycles to make "tree_study_lookup" much faster. And obviously most tree lookups wouldn't want to make this tradeoff, but there may be a few other places that look in the same tree several times, and we can benchmark them to see if they benefit. And if and when faster non-studied tree lookup comes about, we can adjust the tree studying algorithm easily. -Peff -- 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