bug-gnulib
[Top][All Lists]
Advanced

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

Re: avoiding 'static inline'


From: Bruno Haible
Subject: Re: avoiding 'static inline'
Date: Sun, 19 Aug 2012 22:14:59 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Hi Paul,

> I recently added a bunch of static inline functions to Emacs,
> and just for fun I tried changing them to plain 'static' to
> see how much that would hurt performance.  To my surprise, it
> made Emacs 14% faster on my standard Lisp benchmark (taking the nth
> element of a long list).  It also shrank the size of the text segment
> by 1.7%, which was not as much of a surprise.

This simply means that the specific functions you used 'inline' on are
too large.

My background knowledge about inlining is:
  - Inlining is worth it when the function is small (ca. 3-5 instructions),
    so that the inlined code is smaller or otherwise faster to execute
    than an explicit function call (which also takes 3-5 instructions on
    average).
  - I've seen speedups of 10% just by replacing 'static' with 'static inline'
    on judiciously chosen functions in the past (with "gcc -O2" a couple
    of years ago).

> Clearly I've been using 'static inline' too much.

OK, but then to say

> I'd like to install some changes to gnulib, so that its code does
> not use 'static inline' in the modules that Emacs uses.

that is to over-react.

IMO patches
  05/16
  11/16
are OK - these functions were larger than 3-5 instructions. In the case
11/16 I would actually move the function to a .c file (so as to not
bloat every .o file that includes the .h file).

Whereas I object against
  01/16
  03/16
  04/16
  06/16
  07/16
  08/16
  09/16
  10/16
  12/16
  13/16
because inlining is desirable for these small functions, regardless of
compiler. And I object against
  02/16
because for compilers that don't automatically remove unused 'static'
functions this will add a lot of code bloat (multiple copies of the
function).

Patch 14/16 is OK independently, it is a fixup to a 2012-01-10 commit.

Patch 15/16 and 16/16 are also OK independently, they are fixups to
2012-07-28 commits.

Bruno




reply via email to

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