Re: libgit2 - a true git library
- From
Pierre Habouzit <madcoder@debian.org>
- Date
- Nov 2, 2008, 09:25 UTC
- Message-ID
- <20081102092555.GC4066@artemis>
- In-Reply-To
- <20081102015611.GH15463@spearce.org>
On Sun, Nov 02, 2008 at 01:56:11AM +0000, Shawn O. Pearce wrote:
Show 12 quoted lines
> 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...
Show 7 quoted lines
> 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