The primary benefit of compressed debug sections is a size reduction of objects. However, compression imposes additional costs in runtime and memory use at all stages of development
The compiler must produce each debug section in uncompressed form, allocate additional memory for the compressed version, and perform the compression.
When reading an input object, the link-editor must read the compressed data into memory, allocate additional memory to hold the decompressed data, and perform the decompression.
On output, the link-editor must create an uncompressed version of the resulting debug sections. If compression is requested, additional memory and time are used to create the compressed version.
When a debugger reads an object with compressed debug sections, the debugger must allocate additional memory to hold the decompressed data, and perform the decompression.
Furthermore, compressed debug sections allow for smaller files, but not for larger amounts of information. A common example involves 32-bit objects, which are fundamentally limited to 4 Gbytes due to the use of 32-bit file offsets and sizes within them. It is sometimes assumed that compressing debug data might allow for more debug information to be generated. However, the format of 32-bit debug data also contains 32-bit offsets, and so, is logically constrained to 4 Gbytes in uncompressed form.
For these reasons, compressed debug sections are not recommended for general development, where speed of the compile/link/debug cycle usually outweighs the benefits of smaller debug data. Compressed debug sections may be beneficial in cases where disk space is scarce, or for production objects that are copied widely and debugged rarely.