Binary size reduction after overriding default allocator to system allocator (nightly)

[osa1]

Tried with rustc 1.32.0-nightly (65204a9 2018-11-12).

To reproduce:

• Clone https://github.com/osa1/tiny
• cargo build --release && ls -lha target/release/tiny. You'll see a 2.4M binary.
• Apply this diff

    diff --git a/src/lib.rs b/src/lib.rs
    index 8a41e51..9cae724 100644
    --- a/src/lib.rs
    +++ b/src/lib.rs
    @@ -5,9 +5,6 @@
     #![feature(nll)]
     #![feature(ptr_offset_from)]
  
    -#[global_allocator]
    -static ALLOC: std::alloc::System = std::alloc::System;
    -
     #[cfg(test)]
     extern crate quickcheck;
  

• Repeat the same command. The binary size is now 2.5M.

Originally reported on /r/rust thread.

The reason why I think this is a bug is because the default allocator should already be the system allocator, so overriding the allocator to system allocator should have no effect.

[Mark-Simulacrum]

Cc @japaric @rust-lang/compiler

[eddyb]

cc @alexcrichton

[gnzlbg]

This should not happen. Hmm, can you strip symbols of both versions and see if then they become equal?

[mati865]

@osa1 which system are you using?

I cannot reproduce it on Arch Linux.

[osa1]

This should not happen. Hmm, can you strip symbols of both versions and see if then they become equal?

Nope, 1195288 vs 1199384 bytes after stripping. Still not equal.

@osa1 which system are you using?

Ubuntu 18.04.

[tormol]

I also run Ubuntu 18.04 and can reproduce the results before stripping, but not after:

2509744 default_unstripped
2491976 explicit_unstripped
1150232 default_stripped
1150232 explicit_stripped

The stripped binaries differ, but the output of nm contains too much noise for the diffs to be useful.

Versions:

$ rustc --version --verbose
rustc 1.32.0-nightly (6e9b84296 2018-11-10)
binary: rustc
commit-hash: 6e9b84296223126a0a59bde63a0f97011bb7b0f5
commit-date: 2018-11-10
host: x86_64-unknown-linux-gnu
release: 1.32.0-nightly
LLVM version: 8.0
$ strip --version
GNU strip (GNU Binutils for Ubuntu) 2.30
<snip>

[alexcrichton]

I think this is not really a bug nor an issue and would be in favor of closing it. The way the default is injected is every-so-subtly different than using #[global_allocator], they're not byte-for-byte equal (and we don't really have much reason to make them so). The binary sizes don't really matter so much as the stripped binary sizes (no debug info), and if those are close enough to one another then there's not really much to do here.

If there's a large discrepancy then there may be a bug, otherwise this is probably just that libstd can inline better than #[global_alloctor], which LTO can paper over.

[estebank]

@alexcrichton should we close this ticket then?