Мобильная версияКод: Выделить всё
./build x86_64-linux-gnu broadwell
Увеличение размера в 30 раз означает, что каждый фрагмент информации предоставленный в исходных файлах, был 29 раз «переведен» в какую-либо другую форму в процессе.
Давайте проанализируем процесс сборки исполняемого файла из исходного кода. На каком этапе сборки происходит обширное повторение ввода, способное объяснить, что после сборки каталог с исходным кодом и всеми остальными файлами, включая полученный исполняемый файл, увеличивается в 30 раз?
Что я такое известно следующее: у нас есть файл исходного кода... он предварительно обрабатывается и сохраняется. Это удваивает объем данных, представленных в источнике. Теперь оно там дважды. В качестве источника и предварительно обработанного файла. Хорошо, следующий шаг — токенизация: файл переводится в проиндексированные и помеченные токены. Это немного добавляет к исходному контенту, поскольку добавляются метки, придающие токенам контекст и значение. Теперь мы получаем размер файлов исходного кода в 3,5 раза. Затем токены преобразуются в инструкции ЦП — это в общей сложности в 4,5 раза превышает исходный размер кода в различных формах, то есть «языках». Но этого далеко не достаточно, чтобы объяснить 30 раз... так что есть еще более 20 других форм/языков, на которые переводится/дублируется файл исходного кода... на какие именно?
Давайте рассмотрим процесс как последовательность переводов с одного языка на другой: понятный машине формат — это машинный «язык»… язык, на котором говорит машина/процессор. Файл исходного кода предварительно обрабатывается и переводится на язык, понятный токенизатору... токенизатор переводит его на язык, понятный части, создающей инструкции ЦП из токенизаторов... это цепочка переводов на следующий язык, понятный последующему инструменту... это как что-то излагать на японском языке и из-за отсутствия переводчика с японского на русский нужно сначала переводить на английский, а потом уже оттуда на русский, что дает увеличение в три раза в размере, а не в два раза.
Другими словами, умный гений, способный транслировать исходный код непосредственно в машинный код, недоступен... но доступны некоторые специализированные промежуточные трансляторы, поэтому они цепочки для получения результата, а следы того, как их выходные данные являются входными данными для следующих шагов, сохраняются на диске в виде файлов. При 30-кратном дублировании кода должно быть как минимум более 20 промежуточных шагов, о которых я не знаю... каких???
Вот некоторые цифры:
- 45 МБ: zig-bootstrap-0.12.0.tar.xz
- 370 МБ: из извлеченного архива [zig-bootstrap-0.12.0 ]
- 10,7 ГБ: размер [zig-bootstrap-0.12.0] после завершения сборки.
- 158 МБ: размер исполняемого файла сборки. [zig-bootstrap-0.12.0]/out/zig-x86_64-linux-gnu-broadwell/zig
Код: Выделить всё
~ $ pwd
/home/o/oOo/@@/zigPrgLang/zig-bootstrap-0.12.0
~ $ du --max-depth=7 --bytes | sort -n --reverse | head -n 21
11534816050 .
9798353789 ./out
3641046291 ./out/build-llvm-host
2396029965 ./out/host
1946493794 ./out/build-llvm-x86_64-linux-gnu-broadwell
1845856812 ./out/build-llvm-host/bin
1707984748 ./out/host/bin
1518799725 ./zig
1413107665 ./out/build-llvm-host/lib
1378744641 ./out/build-llvm-x86_64-linux-gnu-broadwell/lib
1330181057 ./zig/zig-cache
1193590140 ./zig/zig-cache/o
1020543936 ./out/build-zig-host
654602936 ./out/build-llvm-x86_64-linux-gnu-broadwell/lib/Target
647543403 ./out/build-llvm-host/lib/Target
642163088 ./out/host/lib
481527064 ./out/x86_64-linux-gnu-broadwell
435528487 ./out/x86_64-linux-gnu-broadwell/lib
353705094 ./out/build-llvm-host/tools
333373368 ./out/build-zig-host/stage3
311775221 ./out/zig-x86_64-linux-gnu-broadwell
p>
Я уже спрашивал у всезнающего ИИ и искал в Интернете. ИИ подтверждает, что такое увеличение размера является обычным явлением, но не сообщает подробностей. Мои поиски в Интернете не нашли объяснения вплоть до перечисления шагов и предполагаемого размера дублирования информации, которую они сохраняют на диск в виде файлов.
И да... я это знаю то же самое происходит и с Растом. Кстати, я избегаю, например, KDE Desktop из-за их «философии», которая приводит к тому, что на систему разработки тратятся тонны гигабайт, а Gigabyte достигает количества необходимых загрузок (это делает, например, редактор Kate бесполезным для небольших корректировок, потому что для того, чтобы скомпилировав его из исходников, вам придется потратить гигабайты сетевого трафика только на необходимые загрузки).
Подробнее здесь: https://stackoverflow.com/questions/784 ... times-whil
