This is the mail archive of the
mailing list for the GCC project.
Re: On inlining in C++
- From: dewar at gnat dot com (Robert Dewar)
- To: kunert at physik dot tu-dresden dot de, mrs at apple dot com
- Cc: gcc at gcc dot gnu dot org, gdr at integrable-solutions dot net, jbuck at synopsys dot com
- Date: Tue, 5 Aug 2003 10:49:44 -0400 (EDT)
- Subject: Re: On inlining in C++
> - How much total time does the code spent in the function. If this time is
> only a few micro seconds, there is absolutely no point in inlining.
This is not nearly so simple as you think. Because of the phenomenon of
cache thrashing, you can get a procedure which looks very tiny, and the
timings of your chip may imply that the call is almost free (e.g. on the
power architecture), but because of cache thrashing you get horrible
behavior in a loop.
> The programmer has the complete picture. He has an idea about the actual
> parameters passed to the function. He can actually measure the time.
> He knows if some function is critical or not.
Well for sure that's not true, to have the complete picture requires an
exact simulation of cache behavior and in any case with hundreds of
instructions in flight, analyzing what is going on can be very very hard.
> Maybe someday in the distant future compilers are smart enough to find out
> these things. But currently I strongly prefer to control inlining myself,
> because in most cases I know better.
Possibly, but it is likely to be a case of the blind leading the blind, since
often neither the programmer nor the compiler really know enough.
Fortunately, as someone pointed out, in exewcution time, it is fairly unusual
that inlining can make a difference (we certainly have some customers with
very large critical applications, e.g. in air traffic control,, where it
does make a difference, but this is not the norm). One effect you do want
to avoid is some huge blowup in code size, which in the worst case blows
up the compiler as well.