On Wed, Sep 05, 2007 at 08:05:24AM +0000, Junio C Hamano wrote: > Pierre Habouzit writes: > > > oh boy, yes I fixed that in my local patch collection. I'm waiting for > > a few hours (days ?) to see if there will be some more comments, I've > > integrated every single one done here already (and some I had on IRC > > too), and I'll repost a new clean series that I intend to be a real > > proposal for inclusion. > > Ah, I actually did the single trivial fix-up (ALLOC_GROW) and > have been looking at it, but I'll discard it. Thanks. Yeah I integrated that as well already. I think I'll post the patches at the end of the Day (French Timezone so in 5 or 6 hours at least) to be sure nobody has any good remarks to do first. If you want I can share my branch somewhere if you want to look at it, just ask. > > And yes, this patch is a perfect example of the gain we have to share > > a common buffer API. The code looks (at least to me) way nicer, and if > > you look in the details, we perform as many memory allocations, copies, > > and so on as in the previous version. > > Wait. What is your point in saying this? Is that a good thing > to do "as many"? "API is cleaned-up and it is much easier to > read but we do not do more than before" is certainly a *BIG* > plus, so perhaps that is what you meant, but when I first read > it I thought you were saying "we are not optimizing it at all" > in a negative sense. Sorry if I chose wrong words to say that, it is clearly a big plus ! I wrote it having in mind that very often abstractions and high level APIs often degrade performance. It does not, and that's a huge win. The point is that "despite the somehow higher level API we don't loose an inch of performance". -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org