Re: libgit2 - a true git library

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Sun, Nov 02, 2008 at 01:56:11AM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > 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.

The problem is not the function call, it's really cheap on modern CPUs.
The problem is that across a function call the compiler cannot make
some kind of optimizations and _that_ isn't cheap.

For example, pointers whose value have been loaded from the store into a
register have to be loaded again. A function call trashes all the
registers, etc...


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

Well I fear it'll be more than a few percent harm, and I can already see
Linus argue against the switch to libgit2 for git-core because it lost
2% performances ;P

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]