@@ -1711,7 +1711,7 @@ pub fn build_session_options_and_crate_config(matches: &getopts::Matches)
17111711
17121712 let codegen_units = codegen_units. unwrap_or_else ( || {
17131713 match opt_level {
1714- // If we're compiling at `-O0` then default to 32 codegen units.
1714+ // If we're compiling at `-O0` then default to 16 codegen units.
17151715 // The number here shouldn't matter too too much as debug mode
17161716 // builds don't rely on performance at all, meaning that lost
17171717 // opportunities for inlining through multiple codegen units is
@@ -1729,7 +1729,21 @@ pub fn build_session_options_and_crate_config(matches: &getopts::Matches)
17291729 // unit takes *too* long to build we'll be guaranteed that all
17301730 // cpus will finish pretty closely to one another and we should
17311731 // make relatively optimal use of system resources
1732- OptLevel :: No => 32 ,
1732+ //
1733+ // Another note worth mentioning here, however, is that this number
1734+ // isn't *too* high. When codegen units are increased that means we
1735+ // currently have to codegen `#[inline]` functions into each codegen
1736+ // unit, which means the more codegen units we're using the more we
1737+ // may be generating. In other words, increasing codegen units may
1738+ // increase the overall work the compiler does. If we don't have
1739+ // enough cores to make up for this loss then increasing the number
1740+ // of codegen units could become an overall loss!
1741+ //
1742+ // As a result we choose a hopefully conservative value 16, which
1743+ // should be more than the number of cpus of most hardware compiling
1744+ // Rust but also not too much for 2-4 core machines to have too much
1745+ // loss of compile time.
1746+ OptLevel :: No => 16 ,
17331747
17341748 // All other optimization levels default use one codegen unit,
17351749 // the historical default in Rust for a Long Time.
0 commit comments