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
