David Megginson wrote: > The biggest surprise was that inlining methods made things slower, not > faster, in most cases (there were a couple of exceptions). That may > be a quirk of G++'s code generation, but it's probably worth > considering -- I had inlined much of the infrastructure to try to > speed things up, but then put it back out of line again piece by > piece.
It's probably not a quirk. Inlining actually helps very little except for VERY small functions. It used to be that a function call was slow -- you had to spill a bunch of registers and a return value onto the stack, and then clean them up later. But modern processors can, for the most part, stick all that mess into into a few extra pipeline stages. And all the extra code takes up extra cache lines, that are critical to performance on modern memories. So naively inlined code can actually be slower. It's also worth pointing out that needless inlining can bloat not only code, but compile times. FlightGear, frankly, takes forever to compile -- 17-18 minutes on my Athlon 950. Some of the bigger files pull in ungodly numbers of include files. I was playing recently with (I think) panel.cxx, and waiting for it to compile. A simple gcc -E on the file turned the ~50k of source code into a (no kidding) 750k wad for the compiler to choke on, due to all the code in all the include files. Check out gcc -M and gawk at the sheer number of included files. :) Some of this is the fault of the standard library, and can't be helped (except by dumping it, that is). But a lot of it is our own code, and could be productively removed from the header files. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
