cvs commit: src/sys/dev/lnc if_lnc.c

[Poul-Henning Kamp]

In message <20030722235600.X8165 at gamplex.bde.org>, Bruce Evans writes:

>Several places, including if_lnc.c, used __inline to get cleaner code
>at no cost in performance.  Removing __inline adds a tiny cost.

You know, I would have agreed with you on that, if we were talking
about a CPU with no caches, no branch-prediction and no prefetching.

For modern CPUs however it would be hard to prove the above statement
true or false with any sort of measurement setup we have access to,
and it would be even harder if not downright impossible to prove
that the result was generally applicable to a majority of the current
hardware on the market.

In this particular case I think, any effect, positive or negative,
will depend on the ratio of transmitted and received packets (because
RX-only or TX-only irq's might be able to prefetch over the call
but not the inline version)

I would _really_ love to nail up a policy note which says that "inline"
should only be used if it is possible to show an effect, either because
inlining reduces the code size (in this particular case less bytes to
execute is generally an indication of better performance) or by
showing actual performance improvements from the inlining.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.