Re: inline build_string performance

[Dmitry Antipov]

On 06/26/2012 06:53 PM, Paul Eggert wrote:

> This is not an unalloyed win, since it bloats the
> size of the Emacs executable, as callers to build_string
> often now have two function calls (strlen + make_string),
> not one (just build_string).

The core idea of this stuff is to eliminate calls to strlen when an
argument of build_string is a compile-time constant - the compiler
should just replace call to strlen with constant integer.

As of r108741, my binary image has 336 calls to build_string and
26 calls to make_string; r108742 has 34 and 328, respectively, and
~130 calls of make_string are performed with constant 2nd argument
(i.e. strlen was totally optimized away).

> In my environment
> (Fedora 15 x86-64, GCC 4.7.1) this patch adds 5704 bytes (0.25%)
> to the size of the Emacs text.  Presumably this puts
> a bit more pressure on the text cache.

I have just 3664 bytes (GCC 4.7.1 with -O3, stripped):

address@hidden src]$ readelf -S emacs.r108741  | grep -A1 .text
  [14] .text             PROGBITS         000000000040bf20  0000bf20
       0000000000217dc4  0000000000000000  AX       0     0     16
address@hidden src]$ readelf -S emacs.r108742  | grep -A1 .text
  [14] .text             PROGBITS         000000000040bf20  0000bf20
       0000000000218c14  0000000000000000  AX       0     0     16

(Note that I'm always using minimalistic configuration without DBus,
sound support, GTK, and so).

> Has a performance analysis been done on this change
> showing that the code bloat is worth it?

Although I can't say how much of 130 micro-optimizations described above
are on critical paths, I've got promising results - ~2% speedup both for
(indent-region) for xdisp.c buffer and (byte-force-recompile [all Lisp 
sources]).

Dmitry