Bruno Haible <[email protected]> writes: > Hi Simon, > > I have to disagree with your statements: > >> I have always found inline to be a waste of maintainer time due to all >> portability issues. > > 'static inline' is portable (assuming you use AC_C_INLINE).
Still people seem to run into problem with 'inline' from time to time anyway. AC_C_INLINE have been updated from time to time, so there is cost in using and maintaining that too (even if small). > The only maintainer time you spend is to determine whether it's worth > using inline. In the best case, you make an educated guess. In the worst > case, you compile the code with "-O2 -S" once and look at the size of the > inlinable function. This is not a hassle. The inline keyword has added complexity for me when debugging, when using various source code analysation tools, when trying to strip down code to be able to show a brief example, and probably other situations. >> If performance is critical, you are usually better >> of moving to hand-written assembler with a fall-back to a portable C >> implementation. > > If you can gain 10% of speed just by placing a few 'inline' keywords here > and there (takes 15 minutes on a 200 KB large program), then why not do it? If it were that easy, we could write a tool that would do it automatically. For me, even the risk of having humans spend additional time when reviewing/reading/maintaining code is motivation for me to use as little "special" things as possible. A 10% performance increase is for most code paths not noticable -- users can achieve similar results by using different compiler options. However, I realize this is personal opinion and preference, not something objective. I don't have any strong opinion on whether to apply patches or not, it is more important to me that whomever is maintaining each affected module is happy. /Simon
