[Top][All Lists]
[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