Re: Compilation getting slower

[Andreas Jaeger <aj@arthur.rhein-neckar.de>]

>>>>> Dan Pascu writes:

Dan> On  2 Sep, Andreas Jaeger wrote:
>> 
>> One problem going from libc5 to glibc 2.1 is that glibc 2.1 comes with
>> a number of inline functions and macros for the string functions.  Can
>> you try the glibc 2.1 tests again with -D__NO_STRING_INLINES?

Dan> I tried it only for egcs-1.1.2 with "-g -O2"
Dan> Without -D__NO_STRING_INLINES time was 2m58s with -D__NO_STRING_INLINES
Dan> it was 2m48s, so it seems is one of the reasons it runs slower.

Definitly.

Dan> Now, can you please explain me a bit why does glibc2 use those inline
Dan> functions (if they are better why?), and what is the impact on compiling
Dan> software with -D__NO_STRING_INLINES defined?

>From <string.h>:
/* When using GNU CC we provide some optimized versions of selected
   functions from this header.  There are two kinds of optimizations:

   - machine-dependent optimizations, most probably using inline
     assembler code; these might be quite expensive since the code
     size can increase significantly.
     These optimizations are not used unless the symbol
        __USE_STRING_INLINES
     is defined before including this header.

   - machine-independent optimizations which do not increase the
     code size significantly and which optimize mainly situations
     where one or more arguments are compile-time constants.
     These optimizations are used always when the compiler is
     taught to optimize.

   One can inhibit all optimizations by defining __NO_STRING_INLINES.  */

/* Get the machine-dependent optimizations (if any).  */
#  include <bits/string.h>

/* These are generic optimizations which do not add too much inline code.  */
#  include <bits/string2.h>
# endif

Check those for yourself.

I only mentioned it here since this is one significant difference
between glibc 2.1 and libc5 - compile time and performance wise.  For
further discussions, ask on the glibc list
(libc-alpha@sourceware.cygnus.com).

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de