jemalloc-dev is massive

[Jason Evans]

On Apr 18, 2012, at 10:40 AM, Mike Hommey wrote:
> On Wed, Apr 18, 2012 at 07:34:15PM +0200, Mike Hommey wrote:
>> 
>> I just saw that even stripped, libjemalloc.so is massive: 234K on my
>> system. This size goes down to about 180K when using -ffunction-sections
>> -fdata-sections when compiling, and -Wl,--gc-sections when linking.
>> As a comparison, the fork we currently use in Firefox builds as
>> a 32K library.
>> There's also 74K (!) of .bss in jemalloc-dev, vs. <1K in the old Firefox
>> fork. That seems quite excessive.
> 
> I just figured that .bss is only 8K in the -Wl,--gc-sections build. It
> seems most of its size comes from the (disabled at build time) profiler.
> In these 8K, 4K come from the opt_prof_prefix variable, which is not
> stripped out, and 3K from arena_bin_info.


I just committed a change that should allow opt_prof_prefix to be stripped out.  arena_bin_info used to be duplicated in the bins of every arena, so although it increases the binary size, it decreases memory usage.

With the following configuration (similar to what Mozilla currently uses, IIRC), I get a .so that is 135 KiB:

	EXTRA_CFLAGS="-ffunction-sections -fdata-sections"  LDFLAGS=-Wl,--gc-sections ./autogen.sh --disable-fill --disable-valgrind --disable-experimental

That's still a lot bigger than 32 KiB, but is it so terrible?  Most of the bulk appears to be in the mallctl, stats, and util code, which is cold code unless explicitly called.

Jason