diff options
| author | bors <bors@rust-lang.org> | 2013-11-26 22:07:44 -0800 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2013-11-26 22:07:44 -0800 |
| commit | faf4c939fb6c55f0b9d19b1292fa4601169b3c17 (patch) | |
| tree | d4fdf4e1c58c32bed0e3811978e2269edf9bd9f1 /src/rustllvm/RustWrapper.cpp | |
| parent | 82d9033b67d618d5bc51e9b22190c369214db4b9 (diff) | |
| parent | 7ed27b5531ef25a366ab9e0fe537b7053244b947 (diff) | |
| download | rust-faf4c939fb6c55f0b9d19b1292fa4601169b3c17.tar.gz rust-faf4c939fb6c55f0b9d19b1292fa4601169b3c17.zip | |
auto merge of #10670 : eddyb/rust/node-u32, r=alexcrichton
### Rationale There is no reason to support more than 2³² nodes or names at this moment, as compiling something that big (even without considering the quadratic space usage of some analysis passes) would take at least **64GB**. Meanwhile, some can't (or barely can) compile rustc because it requires almost **1.5GB**. ### Potential problems Can someone confirm this doesn't affect metadata (de)serialization? I can't tell myself, I know nothing about it. ### Results Some structures have a size reduction of 25% to 50%: [before](https://gist.github.com/luqmana/3a82a51fa9c86d9191fa) - [after](https://gist.github.com/eddyb/5a75f8973d3d8018afd3). Sadly, there isn't a massive change in the memory used for compiling stage2 librustc (it doesn't go over **1.4GB** as [before](http://huonw.github.io/isrustfastyet/mem/), but I can barely see the difference). However, my own testcase (previously peaking at **1.6GB** in typeck) shows a reduction of **200**-**400MB**.
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
