Re: libgit2 - a true git library

["Shawn O. Pearce" <spearce@spearce.org>]

Pierre Habouzit <madcoder@debian.org> wrote:
> On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
> > How about this?
> > 
> > http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
> 
> FWIW I've read what you say about types, while this is good design to
> make things abstract, accessors are slower _and_ disallow many
> optimizations as it's a function call and that it may clobber all your
> pointers values.

Yea, optimizing C is a bitch.

I'm in favor of accessors *IN THE APPLICATION*.

Within the library's own C code, I think we should expose the struct,
and use its members where it makes sense to.  Especially in the
really tight loops where we don't want to introduce more overhead.

My rationale here is that we can change the struct at any time,
and yet not change the ABI.

> For types that _will_ be in the tight loops, we must make the types
> explicit or it'll bite us hard performance-wise. I'm thinking what is
> "struct object" or "struct commit" in git.git. It's likely that we will
> loose a *lot* of those types are opaque.

Yes, but I'm arguing they should be opaque to the application, and
visible to the library.  Today the application is suffering from
massive fork+exec overhead.  I really don't give a damn if the
application's compiler has to deal with a function call to read
from a private member of an opaque type.  Its still thousands of
CPU instructions less per operation.

Come back to me a year after libgit2 has been widely deployed on
Linux distros and we have multiple applications linking to it.
Lets talk then about the harmful performance problems caused by
making these types opaque to the application.  About that time
we'll also be talking about how great pack v4 is and why its a good
thing those types were opaque, as we didn't have to break the ABI
to introduce it.
 
> It's IMNSHO on the matter that core structures of git _will_ have to be
> made explicit. I'm thinking objects and their "subtypes" (commits,
> trees, blobs). Maybe a couple of things on the same vein.

Sure, but in the library only.

-- 
Shawn.