We should look at the compiler flags we're using that are in: meta/conf/bitbake.conf Richard suggested that we may be able to add compression of debug sections. The idea being that if we compress the objects when in memory, there would be less IO to do. It is not clear if, on modern systems with fast CPUs and fast SSDs, this would result in faster bitbake builds. We'll have to try it and see. Also, are there similar Rust/Go optimizations that we're not using? This is a 5.3 enhancement, for after gcc-15, IMO.
A quick look at the gcc manual for comparession related flags, reveals: -gz[=type] Produce compressed debug sections in DWARF format, if that is supported. If type is not given, the default type depends on the capabilities of the assembler and linker used. type may be one of none (don't compress debug sections), zlib (use zlib compression in ELF gABI format), or zlib-gnu (use zlib compression in traditional GNU format). If the linker doesn't support writing compressed debug sections, the option is rejected. Otherwise, if the assembler does not support them, -gz is silently ignored when producing object files. ... -flto-compression-level=n This option specifies the level of compression used for intermediate language written to LTO object files, and is only meaningful in conjunction with LTO mode (-flto). GCC currently supports two LTO compression algorithms. For zstd, valid values are 0 (no compression) to 19 (maximum compression), while zlib supports values from 0 to 9. Values outside this range are clamped to either minimum or maximum of the supported values. If the option is not given, a default balanced compression setting is used. ... -mcompress Compress all code using the Ft32B code compression scheme.
Ross says we do this for some recipe already. Maybe webkit? Ask Ross if you can't find it. Start with -gz.
If we're going to change the default, it should be at the start of a development cycle so moving to 6.1 for now, and 6.0-M1 once those milestones are created.