Re: Inlining doesn't happen on OS X: big performance problem

[Jan Djärv]

Hello.

19 sep 2013 kl. 23:18 skrev Paul Eggert <address@hidden>:

> On 09/19/13 13:58, Daniel Colascione wrote:
>> I don't see why we've been going through the tree and replacing
>> instances of "static inline" with "static"
> 
> See bug#12541; removing the "inline" helped performance slightly there.
> 
> More generally, these days "inline" is mostly a noise word for static
> functions, just as "register" is a noise word for locals.  Modern
> compilers inline static functions pretty well without "inline", just
> as they allocate registers pretty well without "register", and it
> saves maintenance hassle if developers don't have to waste their
> time reading the "inline" noise and worrying about whether the
> "inline" should be there.

Please do not try to motivate the current Emacs inline handling with saved 
maintenance hassle.  Maintenance is now a magnitude worse than before due to 
the complicated inline handling.

Before:

1) See INLINE in code.
2) Check out INLINE define in config.h
3) Write your new INLINE function.

Now:

1) See SYSTEM_INLINE in code.
2) Find where it is defined, 2 places, either to INLINE (as _GL_INLINE) or 
EXTERN_INLINE
    (as _GL_EXTERN_INLINE).
3) Figure out if INLINE or EXTERN_INLINE applies to the case at hand.
4) Find definition of _GL_INLINE and _GL_EXTERN_INLINE.
5) Manually parse complicated conditionals to see which define applies.
6) Sigh when you realize that there are unique preprocessor defines of inline 
per file.
7) Don't use inline as it is too complicated and convince yourself that is is 
OK as machines gets
    faster and faster.

Also note that there are still 'static inline' in the w32-code, so if I saw 
that, I might come to the conclusion that 'static inline' is OK.

I'm sure there is some motivation for the inline mess we have now, but 
performance is not it (previously we had fast macros) and maintenance is 
absolutely not it either.

        Jan D.