# Why does \`cargo build\` not optimise by default?

**URL:** https://users.rust-lang.org/t/why-does-cargo-build-not-optimise-by-default/4150
**Category:** uncategorized
**Created:** [January 3, 2016, 11:09am UTC](https://users.rust-lang.org/t/why-does-cargo-build-not-optimise-by-default/4150 "2016-01-03T11:09:11Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![huon](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/huon/32/19_2.png) [@huon](https://users.rust-lang.org/u/huon)
#### Post date: [January 3, 2016, 1:27pm UTC](https://users.rust-lang.org/t/why-does-cargo-build-not-optimise-by-default/4150/3 "2016-01-03T13:27:23Z")

</div>

Optimisations get in the way of a nice compile-test/debug cycle for several reasons:

- they take time (as @DanielKeep says)
- they hinder debugging:
  - inlining of functions means `panic!` backtraces (by setting `RUST_BACKTRACE=1`) may not point to the actual function that caused the problem
  - more generally, it is non-trivial to preserve good debug info (as used by debuggers like gdb) in the presence of optimisation, so getting gdb to connect a certain chunk of instructions back to the code that generates it may be hard-to-impossible

Also, a release build (for Rust software but also C/C++, etc.) would generally not have any debug information at all and would often have (the most expensive/most conservative) assertions turned off. Cargo's `--release` flag by default not only enables optimisations, but also disables debug info & debug assertions, making the debugging experience extremely annoying, and hiding any bugs that would be revealed by detection of, for example, integer overflow (one of the debug assertions).

---

_[View the full topic](https://users.rust-lang.org/t/why-does-cargo-build-not-optimise-by-default/4150)._