Почему минимальный размер приложения такой большой?

Question

[dollar]

Пытаюсь скомпилировать "пустышку":

fn main() {
}

В итоге получается приложение 127 килобайт.

Я понимаю, если бы я использовал функцию, которая в какой-то библиотеке, и Rust включил бы полностью эту библиотеку в exe'шник. Хотя это тоже печально бы выглядело. Но ведь здесь вообще нет вызовов! Что же там такого содержится ценного в файле, без чего не обойтись?

Здесь не должно быть ни сборщика мусора, ни виртуальной машины, ничего такого.

Comments

[Толстый Лорри]

если бы я использовал функцию, которая в какой-то библиотеке, и Rust включил бы полностью эту библиотеку в exe'шник.

Нет, одна из задач компоновщика - выбрасывать лишний код. В exe окажется ровно то, что хоть как-то достижимо (прямо или косвенно) из имеющегося кода при статической линковке.

Answer 1

[Tyranron]

Избитая тема, которая уже подымалась и изучалась не один раз. Достаточно сделать: https://www.google.com/search?q=rust+binary+size и сразу попадаем на статью Rustlog: Why is a Rust executable large?. Настоятельно рекомендую к прочтению, хоть она и слегка устарела (Rust больше не использует jemalloc по умолчанию), но вопрос там разобран крайне детально.

Если коротко, то в Ваш бинарь попадают:
1. Если собирали не в release mode, то debug-символы.
2. Аллокатор, либо код-клей для системного аллокатора.
3. Код для panic unwinding (в том числе и libbacktrace).
4. Части libstd Rust'а, даже если Вы их не используете.

Если стоит задача минимизировать бинарь Rust (под всякий embedded, к примеру), то обычно делают #![no_std], юзают мини-аллокаторы, делают panic = abort и идут на другие лишения.

Comments

[Андрей Леснико́в]

https://github.com/johnthagen/min-sized-rust вот еще ссылка хорошая насчет минимизации размеров

[dollar]

Nikolay Petyukh, дело не только в минимализме. Хотя, будь минимализм в приоритете, современные ОС не весили бы гигабайты, в том числе в оперативке (актуальная проблема современности), это же касается браузеров (тоже актуальная проблема современности), но это уже другая история.

Во-первых, если знаешь, что есть "пустышка" в 62 байта и практически 3d игрушка в 5 килобайт, то ожидаешь от сравнимого с С++ языка чего-то подобного. Ещё раз повторю мысль о том, что здесь вообще нет операторов, даже нет println, то есть тянуть с собой какую-либо библиотеку по идее нет смысла. Оказалось, что есть. И были опасения, что если с начала такой размер, то как же раздувается код в будущем. Оказалось, что всё не так страшно, и дальше этот оверхед не растет по мере добавления кода.

Во-вторых, было интересно, что под капотом. Это полезно чисто для понимания, что даёт язык из коробки. Как оказалось, это всё можно вычищать, и это даёт ещё больше понимания, чего лишаешься и зачем оно нужно, и нужно ли вообще для специфической цели. Так что спасибо за развернутый ответ.

[Tyranron]

Nikolay Petyukh, во всяких embedded часто бывает как ограничен ресурс по памяти, так и по вычислениям. Есть классическая байка на эту тему: История одного байта.

Помимо embedded, тот же фронт-энд в браузере. Чем меньше размер бандла на скачивание/запуск, тем лучше и производительнее приложение. Тот же wee_alloc именно под эту цель и запилили, хоть он в рантайме и медленнее стандартных аллокаторов.

Answer 2

[grinat]

В гоу по моему 2мб мин размер, в приложении скомпилированном андроид студией, где размер таки важен, минимум 3.7мб выходит. Так шо 120кб в наши времена это хороший результат для хело ворда.

Comments

[abmanimenja]

В Go это идеологическое решение.
Решение принято для полной независимости от наличиствующих библиотек (.so/.dll) на той или иной конкретной системе.
Поэтому по умолчанию в бинарный файл Go библиотеки слинкованы статичеси, а не динамически.

При использовании Go с компилятором cgo а не с дефолтным - можно и в Go размер бинарника очень сильно сократить.

[i-zemlya]

abmanimenja, как можно сократить размер бинарника Go?

[abmanimenja]

i-zemlya,
Много способов
https://blog.filippo.io/shrink-your-go-binaries-wi...
https://stackoverflow.com/questions/3861634/how-to...