This was a fun one. Here’s my newest post on how to dramatically reduce Godot’s build size.
Some sacrifices were made… But the end result is a Godot project that works exactly the same, albeit with slightly worse performance. Hope this can help others in achieving tiny build sizes!
The write up has lots of hard numbers for the executable size but only describes the performance impact in general terms.
It would be good to see some before and after performance numbers.
Performance testing is a whole can of worms. It’s hard to get an idea of how performance changes because it’ll depend a lot on the nodes and scripts being used. There could be huge regressions in specific cases and functions and no difference in others. Usually you’ll need a suite of tests to see what changed.
Similar but slightly different reply to Kelly’s, not really responding to your comment on testing viability (though I don’t feel like this comment should be a top-level comment).
It seems to me that at least for opt=size, it actually did improve performance (for a basic benchmark at least) somewhat for low cost compared to no flags. I’m sure this is not as fast as opt=speed, but I would call that more of a trade-off than a sacrifice especially when also considering compilation-time to get a measure of efficiency.
At least that was my impression with Clang (which I was seeing size-optimized Clang giving decent performance but half the compilation time of default GCC). An efficient middle-ground.
EDIT: Though this was also for code (via bindings) not Godot/exports themselves, so it could be different (though I’m not sure why unless a difference of defaults).