I’ve always done this without setting
optimize = true, because I was worried about the quality of backtraces in optimized code. Not having used an optimized debug build before, I’m not sure how much the other debug options help to alleviate this.
That said, there’s no doubt that setting
optimize = true on a debug build significantly helps close the gap between debug and release builds in terms of both time spent and disk space used. (down to about a 30% slowdown, as seen in the data below)
One last remark: I seriously don’t understand why
debug = true affects a whole bunch of (unspecified) configuration settings like it’s supposed to be some big red Easy button… and then tells you that you probably don’t want to use it.
A spattering of data
(all default settings)
(forgot to record this, but IIRC it's usually around 3.5G total)
Debug build with
optimize = true:
debug = true
optimize = true # (note: usually disabled by debug)
debug-assertions = true # (note: enabled anyways by debug, just being explicit)
debuginfo = true # (note: enabled anyways by debug, just being explicit)
debuginfo-lines = true # (ummm... I think I just arbitrarily set this because
it's in the vicinity of the others)
debug = true, unoptimized
Haven’t done this recently (need a large block of time), but from what I remember, the time is somewhere in the ballpark of 2-6 hours, and the total filesize exceeds 13G. (it looks like at some point I did an
rm -rf stage0* stage1* on my saved copy, which trimmed it down to 3.3G).