9 ms·

The base would consume “up to once”. You will only load pages touched, and they are all reclaimable under memory pressure. Memory used by UPX for decompression

The base would consume “up to once”. You will only load pages touched, and they are all reclaimable under memory pressure. Memory used by UPX for decompression is guaranteed to be used, and is not reclaimable! So in fact, it’s not might use more resources, it’s guaranteed to use more resources. The only benefit of UPX is saving disk space, which is unlikely to be super useful to most people these days.

paulfurtado 6y ago
The other use case is to distribute images more quickly over the network and improve image pull times, at the expense of slightly more memory use. Similar to how saving disk is less useful to most people these days, RAM on servers in big docker/kubernetes clusters is also likely not much of a concern for binaries that are well under 100MB if you're not running a ton of copies on each server. In particular, it seems like this tradeoff is most useful for static go binaries, which don't benefit from shared system libraries and aren't likely to have many copies per server, but of course that definitely depends on the use case and I definitely do not recommend blindly using UPX without considering the tradeoffs. It would be an amazing integration though if it were possible to integrate UPX with docker's layer compression such that the binary is extracted to the FS before running. But given how it all works, that's pretty challenging to implement and the network is only getting faster...
- shawnz 5y ago
  Are you sure UPX actually beats the standard layer compression which is already provided? After applying UPX, the result should be nearly uncompressable, so if UPX performs worse than layer compression then it might be better for network usage to not use it at all. In this scenario where you are unpacking it in advance, that eliminates the main benefit of UPX which is that it is self-extracting.
- deleted 5y ago
  [deleted]

paulfurtado 6y ago

The other use case is to distribute images more quickly over the network and improve image pull times, at the expense of slightly more memory use. Similar to how saving disk is less useful to most people these days, RAM on servers in big docker/kubernetes clusters is also likely not much of a concern for binaries that are well under 100MB if you're not running a ton of copies on each server. In particular, it seems like this tradeoff is most useful for static go binaries, which don't benefit from shared system libraries and aren't likely to have many copies per server, but of course that definitely depends on the use case and I definitely do not recommend blindly using UPX without considering the tradeoffs. It would be an amazing integration though if it were possible to integrate UPX with docker's layer compression such that the binary is extracted to the FS before running. But given how it all works, that's pretty challenging to implement and the network is only getting faster...

shawnz 5y ago
Are you sure UPX actually beats the standard layer compression which is already provided? After applying UPX, the result should be nearly uncompressable, so if UPX performs worse than layer compression then it might be better for network usage to not use it at all. In this scenario where you are unpacking it in advance, that eliminates the main benefit of UPX which is that it is self-extracting.
deleted 5y ago
[deleted]