Why do Rust programs use so much more memory than the C, Haskell and OCaml versions?

Question

I looked at how much RAM was used by Rust programs (RES column from top command) and I wonder why they use so much memory.

Here is an example:

use std::io;  fn main() {     println!("What's your name?");     let mut input = String::new();     io::stdin().read_line(&mut input).unwrap();     println!("Hello {}!", input); } 

I saw that 6 MB of memory was used before I input something.

Here is how I compiled and executed the program:

cargo build --release ./target/release/main 

The equivalent C program:

#include <stdio.h>  int main(void) {     printf("What's your name?\n");     char input[100] = {0};     scanf("%s", input);     printf("Hello %s!\n", input);     return 0; } 

only uses 0.6 MB. In this case, the Rust program uses 10 times more memory. In other cases, I saw that the Rust program uses 5 times more memory.

I also tested with other languages to compare.

The OCaml version:

let () =     print_endline "What's your name?";     let line = read_line () in     print_string "Hello ";     print_endline line 

uses 1 MB.

The Haskell version:

main = do     putStrLn "What's your name?"     name <- getLine     putStrLn ("Hello " ++ name ++ "!") 

uses 3 MB.

The Python version:

print("What's your name?") name = input() print("Hello", name, "!") 

uses 7 MB, almost the same as the Rust version!

Update

I'm running Linux (ArchLinux) with Rust 1.3 (I also tried the nightly with similar results).

Update 2

Here is more data from the htop command:

VIRT    RES     SHR     MEM%    Command 15572   2936    804     0.1     ocaml 21728   2732    2528    0.1     haskell 22540   7480    4308    0.2     python 4056    668     600     0.0     c 24180   6164    1928    0.2     rust 

Update 3

I did more tests with massif to see the memory usage.

For every program, I ran massif twice, as following:

valgrind --tool=massif --time-unit=B ./program valgrind --tool=massif  --pages-as-heap=yes --time-unit=B ./program 

Here are the results with all the programs (as shown by ms_print):

C versions:

https://framabin.org/?dd243f8ec99155bc#Af5cPrcHnz3DsWiOStfwgW8Qq6BTVhogz/46L+sMuSs=

https://framabin.org/?261b9366c3749469#1ztDBkgVly9CanrrWWrJdh3yBFL5PEIW3OI5OLnze/Q=

Rust versions:

https://framabin.org/?0f1bac1c750e97bf#AXwlFYYPHeazq9LfsTOpRBaUTTkb1NfN9ExPorDJud0=

https://framabin.org/?c24b21b01af36782#OLFWdwLjVG2t7eoLqLFhe0Pp8Q8pA2S/oq4jdRRWPzI=

OCaml versions:

https://framabin.org/?060f05bea318109c#/OJQ8reHCU3CzzJ5NCOCLOYJQFnA1VgxqAIVjgQWX9I=

https://framabin.org/?8ff1ffb6d03cb37a#GN8bq3Wrm6tNWaINIhMAr4ieltLtOPjuZ4Ynof9bV4w=

Haskell versions:

https://framabin.org/?b204bd978b8c1fd8#DyQH862AM8NEPTKlzEcZgoapPaZLdlF9W3dRn47K5yU=

https://framabin.org/?ac1aa89fcaeb782c#TQ+uAiqerjHuuEEIhehVitjm63nc3wu5wfivAeBH5uI=

Python versions:

https://framabin.org/?197e8b90df5373ec#aOi0+tEj32Na5jW66Kl97q2lsjSZ2x7Cwl/pOt0lYIM=

https://framabin.org/?397efa22484e3992#1ylOrmjKaA9Hg7gw7H7rKGM0MyxuvKwPNN1J/jLEMrk=

Summary (ram usage):

|------------|----------|----------|----------|----------|----------| |            |     C    | Haskell  |   OCaml  |   Rust   |  Python  | |------------|----------|----------|----------|----------|----------| | First run  |    1 B   | 63.12 KB | 5.993 MB |   816 B  | 1.321 MB | |------------|----------|----------|----------|----------|----------| | Second run | 6.031 MB | 24.20 MB | 17.14 MB | 25.60 MB | 27.43 MB | |------------|----------|----------|----------|----------|----------| 

The first run is without the --pages-as-heap=yes parameter.

I also ran massif with the --stacks=yes option for C and Rust.

C version:

https://framabin.org/?b3009d198ccfdee1#HxR6LPPAzt15K+wIFdaqlfSJjBrJvhV2ZHWdElg3ezc=

(3.141 KB)

Rust version:

https://framabin.org/?b446d8d76c279007#tHnGiOnRstTA2krhz6cgfvTjI+FclcZS3rqyZvquWdQ=

(8.602 KB)

What does explain such a huge difference between heap block allocation and page allocation in Rust?

Answer 1

Because the standard library is statically linked.

You can overcome this by compiling with the -C prefer-dynamic option.

As to the reason behind having the standard library statically linked: it increases executable portability (ie: no need for the standard library to be installed in target system).