apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <d...@haxent.com.br>
Subject Re: apr_pools hairsplitting
Date Tue, 17 Jul 2007 13:49:20 GMT
Joe Orton wrote:
> On Wed, Jul 11, 2007 at 03:59:22PM -0300, Davi Arnaut wrote:
>> Before:
>>
>>    text    data     bss     dec     hex filename
>>  164467    3664     232  168363   291ab libapr-1.so.0.3.0
> ...
>> After:
>>
>>    text    data     bss     dec     hex filename
>>  162033    3680     232  165945   28839 libapr-1.so.0.3.0
> 
> Have you looked at where the text size reduction comes from?  Fewer 
> static functions being inlined?

mostly from the uninline of allocator_alloc and allocator_free.

> In principle this looks good, though it's annoying that it forces a 
> bunch of stuff to be global rather than static.

I was planning to use the gcc visibility support to hide those symbols
(and others internal-only). I'm just not sure if we should create a new
APR_INTERNAL(type) with "hidden" visibility or change APR_DECLARE(type)
to a "default" visibility and compile apr with -fvisibility=hidden.

--
Davi Arnaut


Mime
View raw message