bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: avoiding 'static inline'


From: Simon Josefsson
Subject: Re: avoiding 'static inline'
Date: Mon, 20 Aug 2012 09:20:40 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux)

Bruno Haible <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]