Optimize name mangling for binary size wins?

Development Compiler
1

Hey all!

I had a potentially really stupid idea, which may not even save that much space; I was wondering if it was at all sane to pass a compiled/partially compiled swift binary through an optimizer that would replace the relatively long mangled names swift uses with shorter names? I imagine the process resulting in names that would be similar to minified JavaScript.

To not break desymbolication, a new two phase process would have to be introduced which would first map from minified symbols back to swift mangled names (through a stored lookup table generated at optimization time), and then the usual swift demangling that we know and love.

Would this result in a smaller swift binary? I'd love to hear what people think, I'm happy to push this through the evolution process if it seems like a good idea. Swift is still used mostly for iOS apps, and binary size of iOS apps is still a topline metric for a number of different companies & apps - I'm sure they'd love to see smaller apps.

cc @Erik_Eckstein

2

Swift's name mangling is already heavily optimized for size and for the way dyld is implemented. Mangled names are optimized to share common prefixes, so that they maximally share nodes in a Mach-O dylib's lookup trie. We know that code size is an issue, but I don't believe name mangling is a primary source of our code size troubles. You can use strip -T on Mach-O binaries to strip Swift symbols from the nlist (which is the legacy flat list of symbol names, not used by normal dynamic linking but still used for dladdr and some other dynamic linking APIs), but IIRC Xcode does this as part of a release build already (cc @Michael_Gottesman to confirm).

2 Likes
3

IIRC it is done as part of an archive build, not via a release build. That is the right flag to pass to strip.