emacs-devel
[Top][All Lists]
Advanced

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

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


From: Ryan Johnson
Subject: Re: Inlining doesn't happen on OS X: big performance problem
Date: Thu, 19 Sep 2013 09:44:26 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 19/09/2013 9:35 AM, Daniel Colascione wrote:
Currently, gnulib converts "inline" to "static" on OS X. In particular,
config.h uses this logic from m4/extern-inline.m4:

#if ((__GNUC__ \
       ? defined __GNUC_STDC_INLINE__ && __GNUC_STDC_INLINE__ \
       : (199901L <= __STDC_VERSION__ \
          && !defined __HP_cc \
          && !(defined __SUNPRO_C && __STDC__))) \
      && !defined __APPLE__)
...
#elif (2 < __GNUC__ + (7 <= __GNUC_MINOR__) && !defined __STRICT_ANSI__ \
        && !defined __APPLE__)
...
#else
# define _GL_INLINE static _GL_UNUSED
# define _GL_EXTERN_INLINE static _GL_UNUSED
#endif

Using "static" for "inline" comes at a tremendous cost in performance.
Compiling with gcc 4.2.1 -O2, Emacs HEAD takes 113.9 seconds to
font-lock-fontify-buffer lisp.h ten times. If I replace "!defined
__APPLE__" with "1" above, Emacs compiles and runs perfectly well
(albeit with some warnings about missing declarations) and performs the
same task in only 36.8 seconds. Disassembly confirms that in the current
configuration, nothing is actually being inlined.

Can we please remove these "!defined __APPLE__" tests and start inlining
functions again in OS X?

Surely something that elaborate and costly was a conscious decision... have you looked through the revision history to see why this was added in the first place? (The hope is that the reason is no longer valid and the change can be reverted)

Ryan




reply via email to

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