On Sun, Nov 02, 2008 at 01:56:11AM +0000, Shawn O. Pearce wrote: > Pierre Habouzit <madcoder@xxxxxxxxxx> 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpkvDaCwFMnr.pgp
Description: PGP signature
