On Wed, Sep 05, 2007 at 08:05:24AM +0000, Junio C Hamano wrote:
quoted text
> Pierre Habouzit <madcoder@debian.org> writes:
>=20
> >   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.
>=20
> 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.

quoted text
> >   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.
>=20
> 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".

--=20
=C2=B7O=C2=B7  Pierre Habouzit
=C2=B7=C2=B7O                                                madcoder@debia=
n.org
OOO                                                http://www.madism.org