Re: How to make the binaries smaller?
Re: How to make the binaries smaller?
- Subject: Re: How to make the binaries smaller?
- From: tahome izwah <email@hidden>
- Date: Tue, 08 Nov 2011 07:35:29 +0100
I'd first make sure that the size you're seeing is really due to the
size of the actual code. It is more likely that it is due to the
resources that you have in your plug in, like UI gfx. Make sure you
include the resources only where you need them (ie in the cocoa view
factory and not in the actual plug in project as well). You could also
convert them to a different format (reduce word length, get rid of the
alpha channel where you don't need it).
If it really is your code then you're probably using a lot of
const/static data that get hard coded into your binary. I'm sure there
is a gcc option to compress (uninitialized) static arrays, and if you
have a lot of preset data you could load them from a compressed data
file instead of statically linking them in.
HTH
--th
2011/11/7 Jean-Daniel Dupas <email@hidden>:
>
> Le 7 nov. 2011 à 01:06, Vojtěch Meluzín a écrit :
>
>
>>
>> > Hi I'm just checking if someone knows how to make the plugin release
>> > binaries smaller. This is because Mac binaries are really big, and now
>> > having the universal ones containing both 32bit and 64bit versions it became
>> > huge... For example 16 MB per plugin. The thing is that Mac32 is even bigger
>> > than Win64, so I just wonder if there's a way to improve the situation. The
>> > truth is, that I partly think that it's because of the GCC compiler (as
>> > opposed to MSVC on Windows), which is just the best from all I tested,
>> > including Intel compiler. I had quite a few problems with code generated by
>> > Intel compiler, so I'm not using it on Mac.
>> >
>> > I'm currently using GCC, SDK 10.5, default hidden visibility,
>> > -fexceptions, -O2. Then after linking I use "strip -S -x" to remove the
>> > symbol names. I also use statically linked c++ libraries and additional
>> > libs, basically libpng, freetype, zlib - I had a really big issue after
>> > Apple released Snow leopard and some libraries went missing on some
>> > computers and stuff, so I kinda resigned on dynamic linking despite it would
>> > be advantageous in this matter.
>> >
>> > Any idea how to improve it?
>> >
>>
>> What about using -Os or -Oz instead of -O2 ?
>>
>> -Os Optimize for size, but not at the expense of speed. -Os enables all
>> -O2 optimizations that do not typically increase code size. However,
>> instructions are chosen for best performance, regardless of
>> size. To optimize solely for size on Darwin, use -Oz (APPLE ONLY).
>>
>> Also, make sure you enable deadcode stripping in the linker options.
>>
>
> I checked the -Os, in my case it resulted in smaller code, approximately
> -15%, but also slower code, say -5%, not much, but still.
> How to enable the deadcode stripping? I thought the linkers do that always
> :).
>
> Vojtech
>
> In Xcode, in the build option, check the "Dead Code Stripping" option. In
> command line, this is "-dead_strip" ld argument and you may also need
> "-no_dead_strip_inits_and_terms".
> Of course, if using GCC (or clang), you will have to prefix the arguments by
> '-Wl'.
> For details about what they do, check the ld man page.
> On thing you may check too it that you only exports the plugin entrypoint
> symbols. The good way to do this is to use a symbols list (ld option
> -exported_symbols_list ). It greatly helps the linker to know what it can
> deadstrip.
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden