Hi all:
I have a new plugin working, that uses the default vector graphics sliders (I change the look and feel, but I am not including any images). The size of my .component is 11 MB. That seems pretty big to me - the same code, running as a native Audio Unit, takes 320 KB.
Any suggestions on how to reduce the size of this? It will be hard to email it to beta testers with such a size, and the download cost might end up adding up once I release it publicly.
Thanks,
Sean Costello
try a strip.
At the same time, OSX code use Framework (dynamic linking) which explains why the binary are small when using only those.
Don’t email plugin to your beta tester but use something like rapidshare and send them the link.
Mac universals do just seem to be huge, because they contain duplicates of all the code, but that sounds like something’s gone wrong. Have you stripped it properly? Are you linking to libraries that you don’t really need?
But don’t forget that you’ll probably distribute it in a compressed .dmg, so the actual download size will be much better.
(It’s a pity that UPX doesn’t support mac binaries - that tool does a fantastic job of compressing win32 binaries, but on the mac it’d be even more useful)
[quote=“jules”]Mac universals do just seem to be huge, because they contain duplicates of all the code, but that sounds like something’s gone wrong. Have you stripped it properly? Are you linking to libraries that you don’t really need?
[/quote]
My project is directly based off of the demo project from the tip. This also has an 11 MB .component, for the Release build. It gets down to 3.1 MB in a .zip, which is still pretty big for a volume control with a keyboard component. 
So…any tips on how to strip stuff out? What can go for your average plugin?
It is probably a safe assumption that there are many other users that need info on how to do this, since this is a cross-platform framework, and many people are less skilled for a given operating system. I never seem to run into these problems in VisualStudio, but Xcode always throws me for a loop.
Thanks,
Sean Costello
I think I put some stuff about the strip tool in the plugin readme
OK, ran the strip tool from the command window, and the Juce Demo Plugin is now 7.6 MB. Still seems pretty darned big.
Just to make this clear, for people who want to run this:
For example, if you are building the Juce Demo Plugin, you would run the following 2 lines in the Terminal:
cd ~/Library/Audio/Plug-Ins/Components
strip -x -S JuceDemoPlugin.component/Contents/MacOS/JuceDemoPlugin
I’m not sure if this stuff could be put into a script, or if the strip commands could be incorporated into the build itself. Any ideas?
Can you provide more info about what libraries can be removed to reduce the size of the Demo plugin, and how to do so? Can you do this from the Juce Demo Plugin project itself, or do you need to rebuild the Juce project first?
Thanks for your help,
Sean
Hello,
Thanks for the strip script.
BTW here the jucedemoplugin debug is large (around 10Mo) , but a clean release build is much smaller (4Mo).
Surprisingly, if I build release again (without cleaning), then the size comes down to 3.6 Mo. (which is the same size if I strip after a clean build)
Zipped it’s down to 1.4 Mo, which is very resonable IMO 
best,
Salvator
My current plugin is 5 MB for a Universal Binary, with stripping enabled in the build, unnecessary options commented out in juce_amalgamated.h, all that stuff. On the PC, the .dll comes in at around 800 KB. Looks like it’s a Mac thing.
Sean
Yes, mac binaries do tend to be big.
In my previous Windows build, I was only building for VST. Building for both VST and RTAS increased the .dll/.dpm size from 806 kB to 1248 kB. Still smaller than my Mac build - but the Mac build is for Intel and PowerPC, so it makes sense that it would be bigger.