I've taken some time to look into bevy binary size, especially the somewhat absurd 40+ mb of strings which are part of release binaries (i used bloaty and cargo bloat to check the general state of whats big).
- panic_immediate_abort+build_std: doesn't help much at all, even though i noticed a lot of type names when paging through the strings
- codegen units = 1: doesn't help much either
- A very rough attempt at (diy) bisect led me to the conclusion that there wasnt a single cause of this, but binary sizes have just steadily grown since at least 0.15 (I didn't check further back).
- the bevy_utils/debug feature doesn't help much, only a few mb
Finally, to find where the strings are coming from, I wrote a python script which uses radare2 to disassemble any binary and outputs a speedscope.app compatible file which shows the functions accessing strings with the amount of strings they need, attempting to split the type names into flamegraph levels. This seems to only pick up