Normally operating system simply maps binaries, executables and loadable libraries (.dylib, .so, .dll, etc.) into memory. The cost is approximately same whether you do this once or 1000 times. The code is executed from the mapped area as-is.

However, when a binary is compressed, this cannot work, because in the file the binary is represented as a compressed data. The only way you can work around is to allocate some memory, decompress the binary there, map the region as executable and run it from there. This results a non-shareable copy of the data for each running instance.

A random link about this issue in practice: https://github.com/nushell/nushell/issues/4131

Every instance of a program will use an amount of ram equal to the uncompressed size.

If the application is uncompressed, the uncompressed executable will be loaded into ram 1 time and be reused by every instance of the application.

I'm curious, was the practice of using upx there before you got there? We generally A/B test changes like this pretty thoroughly by running load tests against our traffic and looking at things like CPU and Memory pressure in our deploys.