Oh indeed. No argument there.
Depends. We currently have separate parsers for trees, commits, tags,
etc. That should be easy enough to add another (separate) parser for
new tree objects while still having a common higher level accessor
interface like tree_entry().
But right now we only regenerate the text representation whenever the
binary representation is encountered just to make things easy to do, and
yet we still have a performance gain already in _addition_ to a net
saving in disk footprint.
Of course the current tree parser will remain, probably forever. And it
is always a good thing to optimize it further when ever possible.
Sure. But at this point the reference to compare GIT performance
against might be GIT itself. And while 1 second is really nice in this
case, there are some repos where it could be (and has already been
reported to be) much more.
I still have a feeling that we can do even better than we do now. Much
much better than 16% actually. But that require a new data format that
is designed for speed.
We'll see.
Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html