On 28 January 2002 08:30, Andrew Morton wrote:
> > > s/inline//g
> >
> > I like this.
>
> Well, it's a fairly small optimisation, but it's easy.
>
> I did a patch a while back:
> http://www.zip.com.au/~akpm/linux/2.4/2.4.17-pre1/inline.patch This is
> purely against core kernel files:
[snip]
How did you find big inlines? Care to share hunter script with me (+ lkml)?
> The first patch should be against Documentation/CodingStyle.
> What are we trying to achieve here? What are the guidelines
> for when-to and when-to-not? I'd say:
>
> - If a function has a single call site and is static then it
> is always correct to inline.
And what if later you (or someone else!) add another call? You may forget to
remove inline. It adds maintenance trouble while not buying much of speed:
if func is big, inline gains are small, if it's small, it should be inlined
regardless of number of call sites.
> - If a function is very small (20-30 bytes) then inlining
> is correct even if it has many call sites.
Small in asm code, _not_ in C. Sometimes seemingly small C explodes into
horrendous asm.
> - If a function is less-small, and has only one or two
> *commonly called* call sites, then inlining is OK.
How much less small? We can have both:
inline int f_inlined() { ... }
int f() { return f_inline(); }
...
f_inlined(); /* we need speed here */
f(); /* we save space here */
> - If a function is a leaf function, then it is more inlinable
> than a function which makes another function call.
100%. Especially when some "cute small functions" called inside happen to be
inlined too (or are macros).
> fs/inode.c:__sync_one() violates all the above quite
> outrageously :)
Homehow I feel there are more :-)
-- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:58 EST