Комментарии 13
компилирует небольшую программу в режиме релиза, обращает внимание на размер получившегося файла
Впервые увидев такое, я быстро пришел к
[build]
rustflags = ["-Cprefer-dynamic"]в файле .cargo/config.toml
Для того, чтобы это работало, необходим
export LD_LIBRARY_PATH+=:$(rustc --print=sysroot)/libC/С++ работают в подобном режиме, требуя доступ к библиотекам времени выполнения (runtime so/dll).
Забыл уточнить, что по таком подходе HelloWorld получается 16 КБ. Наличие отладочной информации в библиотеках уже не критично. А вот то, что библиотеки грузятся в память один раз на любое количество сервисов на Rust, а не бессмысленно занимают память для каждого сервиса - уже очень заметно.
Замечу, что это будет работать только если бинарь компилировался с точностью той же версией rustc, которая используется при запуске.
У Rust так и нет никакого стабильного ABI, из-за чего нет никаких гарантий, что ваши бинари будут друг с другом совместимы, если компилировались по-разному.
Там вопрос совместимости не стоит. Все библиотеки в имени имеют 64-битную версию в шестнадцатиричном представлении. Если не будет нужной версии - исполняемый файл просто не запустится.
Если в одном контейнере нужно запускать бинарные файлы Rust разных версией с динамической линковкой, то там должны быть библиотеки для каждой из этих версий. Но зачем устраивать самому себе зоопарк, если можно в CI/CD собирать всё одной версией?
Например, в проектах Liinux Kernel и plrust в PostgreSQL версия Rust прибивается гвоздями и её смена подразумевает полную перекомпиляцию. Зато, как я уже указал выше, экономия оперативной памяти получается очень существенная. Только представьте себе, что было бы, если каждый модуль ядра, использующий Rust, тащил бы за собой свою личную копию всех используемых библиотек в память.
Сама концепция статической линковки библиотек в исполняемый файл чем-то похожа на концепцию snap в Ubuntu, со всеми её минусами и плюсами.
"Двоичный" это типа "бинарный"?)
По-моему, 415 килобайт - это все еще многовато для хелоуолда :) Помнится , минимальный ms-dos на дискете плюс-минус столько места занимал :)
Если поиграться с параметрами компиляции, можно ужаться в 14 килобайт
Не верится что такая проблема не была решена в течении 5 лет! Вроде что-то очевидное и задача не выглядит сложной, а столько времени понадобилось чтобы хоть кто-то её сделал
Забавно, всегда считал это нормой. А так, оказывается, не должно было быть.
Есть ещё одна проблема с размером, которая актуальна не только под GNU/Linix. Не все это знают, но в Rust существует размотка стека при panic! (с вызовом деструкторов), которая (якобы) нужна, чтобы очищать ресурсы запаниковавших потоков или очищать ресурсы, если внешний код (C++) кинул исключение.
Так вот, как известно, бесплатных завтраков не бывает, и за размотку стека приходится платить, в данном случае дополнительным размером исполняемого файла. Но если размотка стека не нужна, размеры итоговых исполняемых файлов можно уменьшить, собирая проект с panic = "abort". В моих случаях это даёт выигрыш размера в 25%.
Случай, кстати, во многом аналогичен случаю из данной статьи. На практике корректной обработкой panic! мало кто занимается, ибо считается, что это признак бага в программе. Так что для большинства пользователей умолчательное поведение поддержки размотки стека неверно и ведёт к увеличению размера файлов.
Потому, что она не якобы очищает ресурсы. Например вот из стандартной библиотеки пример, пытаемся записать буфер в дропе (если не сам писатель эту панику кинул). И для этого не нужно эту панику никак специально обрабатывать, скорее возможность эту панику перехватить . По моему мнению лучше по умолчанию все же хотя бы пытаться все нормально закрыть, а не просто умирать.
опытный разработчик на C или C++ решает попробовать Rust, компилирует небольшую программу в режиме релиза, обращает внимание на размер получившегося файла, сразу же отказывается от освоения этого языка
Почему только опытный разработчик? И почему только размер?
Вот кнопка и код к ней выходящий counter++ в slint gui после cargo build даёт 250мб, а с release аж целых 17мб.
Размер не беда. Я вот на него косо смотрю, потому что очень редко попадаются ответы на мои вопросы. То-ли это очень просто и не стоит об этом писать, то-ли наоборот это дико сложно, и об этом нужно молчать. Программу таймер я очень быстро сделал на golang, но в расте........ я пока не смог это осилить. Мне нужен раст+ gui, так как его проще установить на альт линукс, а он у меня везде.
Я вполне могу представить ситуацию, как опытный разработчик на C или C++
решает попробовать Rust, компилирует небольшую программу в режиме
релиза, обращает внимание на размер получившегося файла, сразу же
отказывается от освоения этого языка и идёт потешаться над ним на
форумах.
Проблема понятная и реально существующая, но разработчик какой-то не очень опытный, всё-таки. За десяток лет так и не узнать про strip и отладочные символы...
Делаем двоичные файлы Rust меньше по умолчанию