Достоверное сравнение размера кода

Question

Я написал две разные реализации C алгоритма, который работает на встроенном процессоре (ARM). Я хотел бы честный способ сравнить эти две реализации с точки зрения Размер кода, поэтому при загрузке исполняемого файла я получаю следующие цифры:

Implementation One

 .text size 55098 bytes
 .data size 2048 bytes

Implementation Two

 .text size 54598 bytes
 .data size 2048 bytes

Разница в сегменте .text составляет 500 байт, но в относительном выражении это не так много. Проблема в том, что этот рисунок содержит также загрузочный код, который обернут вокруг исполняемого файла, чтобы его можно было запускать в автономном режиме, то есть без операционной системы на встроенном процессоре.

Мне интересно, есть ли у кого-нибудь идея, как я могу получить ФАКТИЧЕСКИЙ размер кода исполняемого файла без всего раздутого дополнительного кода.

Большое спасибо Andrew

Answer 1

1. Ваш компилятор C обычно может создавать исходный код сборки, который вы можете проверить.
2. Другая возможность - посмотреть на файл карты с помощью компоновщика, он должен дать вам размеры отдельных функций.
3. Вы можете посмотреть двоичный код с помощью отладчика.

Чтобы получить выходные данные или файлы карт asm, вам нужно указать соответствующие опции для компилятора и / или компоновщика. Эти параметры зависят от того, какую цепочку инструментов (компилятор, компоновщик) вы используете.

Чтобы получить вывод asm из gcc: gcc -S -o hello_asm.s hello.c

Answer 2

Ваш компоновщик почти наверняка может сгенерировать файл MAP (и, возможно, уже делает это), который покажет (в мельчайших деталях) детали использования памяти всеми отдельными данными и объектами кода, безусловно, вплоть до уровня объектного модуля, и обычно до уровня отдельных функций и объектов данных.

Answer 3

В конце будет загружен весь код, включая загрузчик и ОС. Так почему вы хотите исключить их из меры?

Простой способ узнать размер кода, который вы хотите исключить, чтобы компилировать с приложением как можно проще (например, main(){}). Тогда вам просто нужно вычесть полученные значения из ваших следующих мер.

Answer 4

Вы могли бы написать «Нулевая реализация», в которой просто есть функция-заглушка, которая ничего не делает. Это даст вам базовое значение для использования в ваших сравнениях.

(первый размер реализации - нулевой размер реализации) против (Размер реализации Два - Размер реализации Null)

Answer 5

Иногда бывает сложно измерить размеры реализаций в отдельности, поскольку некоторые реализации требуют, чтобы библиотечные подпрограммы были связаны, а другие - нет.Если подпрограмма # 1 на 300 байтов меньше, чем # 2, но требует 500-байтовой библиотечной подпрограммы foo (), а подпрограмма # 3 - на 300 байтов меньше # 4, но также требует ту же самую подпрограмму, тогда # 1 в отдельности будет эффективно200 (т.е. 500-300) байтов больше, чем # 2, и # 3 в отдельности будет на 200 байтов больше, чем # 4, но # 1 плюс # 3 будут на 100 байтов меньше, чем # 2 плюс # 4 (поскольку подпрограмма библиотеки будеттребуется только один раз).

Такая ситуация может часто возникать, если создается альтернатива с ограниченной функциональностью (и с уменьшенной стоимостью) некоторой библиотечной подпрограмме.Если можно избежать необходимости в дорогостоящей библиотечной подпрограмме, может оказаться целесообразным написать и использовать более простую версию.С другой стороны, если код все равно использует дорогостоящую подпрограмму, более простая версия может оказаться излишней.

Answer 6

Если вы используете инструменты GNU, вы можете использовать инструмент size.Он сообщит вам количество памяти, используемой в каждом разделе любым объектным файлом.В вашем случае вам нужно убедиться, что код, который вы хотите измерить, находится в своем собственном файле.

Вот пример вывода:

text    data     bss     dec     hex filename
9767       4    5184   14955    3a6b cfi_flash.o
1138       0     192    1330     532 cfi_mtd.o
 556       0     128     684     2ac mtdcore.o
3897       0       8    3905     f41 mtdpart.o

Answer 7

Один из возможных способов - заставить ваши инструменты сборки выгружать карту с большей детализацией.

Например, если вы используете набор инструментов gnu, вы можете использовать run size для файла .elf и получить его разбивку на основе объектных файлов в нем.

Вы также можете использовать objdump в файле .elf, чтобы получить довольно подробную карту.

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

Answer 8

Вы должны определить, что является частью extra code. Надеюсь, вы написали этот дополнительный код в другом модуле компиляции. В вашей цепочке инструментов должны быть инструменты для определения размера кода этих единиц компиляции.

Самое главное, вы должны сравнить размер кода с доступной памятью. Не стоит уменьшать размер кода, если у вас нет требования разместить код в указанной области памяти.