On Mon, 2 Jan 2006, Krzysztof Halasa wrote:
>
> For example, I add "inline" for static functions which are only called
> from one place.
That's actually not a good practice. Two reasons:
- debuggability goes way down. Oops reports give a much nicer call-chain
and better locality for uninlined code.
- Gcc can suck at big functions with lots of local variables. A
function call can be _cheaper_ than trying to inline a function,
regardless of whether it's called once or many times. I've seen
functions that had several silly (and unnecessary) spills suddenly
become quite readable when they were separate functions.
More importantly, the "inline" sticks around. Later on, the function is
used for some other place too, and the inline doesn't get removed.
The second "the inline sticks around" case is something that happens to
helper functions too. They started out as trivial macros in a header file,
but then they get converted to an inline function because they get more
complex, and eventually it grows a new hook. Suddenly what used to
generate two instructions generates ten instructions and a call, and would
have been much better off being uninlined in a .c file.
So inlines that make sense at one point have a tendency to _not_ make
sense a year or two later.
I suspect we'd be best off removing almost all inlines, both from C files
and headers. There are a few cases where inlining really helps: the
function really ends up being just a few instructions, and it's really
just a wrapper around a simpler calling convention or an inline assembly,
or it's called with constant arguments that are better left off simplified
at compile-time. Those are the cases where inlining really helps.
(Of course, then there's ia64. Which wants inlining just because..)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
