Re: libgit2 - a true git library

From: Shawn O. Pearce <spearce@spearce.org>
Date: Nov 2, 2008, 01:56 UTC
Message-ID: <20081102015611.GH15463@spearce.org>
In-Reply-To: <20081101173042.GE26229@artemis.corp>

Pierre Habouzit <madcoder@debian.org> wrote:

Show 9 quoted lines

> 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.