> prior to 1.2, the Go linker was emitting a compressed line table, and the program would decompress it upon initialization at run-time. in Go 1.2, a decision was made to pre-expand the line table in the executable file into its final format suitable for direct use at run-time, without an additional decompression step.
This is a good choice I think and the author of the article missed the
most important point - it uses less memory to have an uncompressed table.
This sounds paradoxical but if a table has to be expanded at runtime
then it has to be loaded into memory.
However if a table is part of the executable, the OS won't even load
it into memory unless it is used and will only page the bits into
memory that are used.
You see the same effect when you compress a binary with UPX (for
example) - the size on disk gets smaller, but because the entire
executable is decompressed into RAM rather than demand paged in, then
it uses more memory.
This is a good choice I think and the author of the article missed the most important point - it uses less memory to have an uncompressed table.
This sounds paradoxical but if a table has to be expanded at runtime then it has to be loaded into memory.
However if a table is part of the executable, the OS won't even load it into memory unless it is used and will only page the bits into memory that are used.
You see the same effect when you compress a binary with UPX (for example) - the size on disk gets smaller, but because the entire executable is decompressed into RAM rather than demand paged in, then it uses more memory.