Как уменьшить размер плагина: Microsoft VC++ 4.2

(замечания к статье Олега Данилова)
Eugene Yavorsky [eugene_yavorsky@mail.ru]eugene_yavorsky@mail.ru

В статье "Как уменьшить размер плагина (на примере Microsoft VC++ 6.0)" Олег Данилов пишет:

Шаг 0. Все функции, используемые, в плагине были заменены на аналогичные
из Win API: strcpy на lstrcpy и т.д. К сожалению, история не сохранила
исходный размер плагина, поэтому оценить экономию на этом шаге затруднительно.

В дополнение привожу результаты моих "издевательств" над двумя собственными проектиками в VC 4.2.

Первая подопытная программа - Win32 GDI, RTL - single-threaded (ключ компиляции /ML). До "измывательства" - 26624 байт (исходный код до "обработки" - до 100 строк, после - 101 строка, из которых 3 - инклуды, 30 - форматирование [пробелы и открывающие/закрывающие скобки], 10 - комментарии, 26 - объявления и инициализация переменных. Итого 32 "смысловые" строки).

В таблице приведены результаты рекомендованных Олегом Даниловым замен (естественно, где было что заменять ;-).

Заменяемая функция Замена До замены После Выигрыш
strlen lstrlen 26624 26112 512
sprintf strcpy+strcat 26112 18432 7680
strcat, strcpy lstrcat, lstrcpy 18432 17920 512

Итого   26624 17920 8704

Наибольший эффект дала замена

sprintf(lpszMessage, "%s\n\"%s\"\n%s", lpszBegin, lpszExe, lpszError);
на
strcpy(lpszMessage, lpszBegin);
strcat(lpszMessage, "\n\"");
strcat(lpszMessage, lpszExe);
strcat(lpszMessage, "\"\n");
strcat(lpszMessage, lpszError);

(естественно, замена сначала на RTL-функции проводилась исключительно в исследовательских целях).

Т.о., для данного приложения выигрыш от замен составил порядка трети. Естественно, если размер скомпилированного приложения или библиотеки больше двух-трех сотен килограмм, "овчинка" (эти 8 КБ) вряд ли стоит выделки.

Так же стоит внести некоторое возражение относительно "отсутствия эффекта от оптимизации по размеру".

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

В рассматриваемом микро-приложении при отключении оптимизации в "окончательном" варианте размер подскакивает с 17920 до 18432 байт (т.е., на каких-то 32 "смысловых" строках оно таки наоптимизировало 512 байт).

При взятии чуть большего приложения, которому даже далеко до "среднего" по размеру программного прожекта (тестовый проект состоял из 21 исходника на C и CPP суммарным размером около 150 килограмм), получаем такую статистику:

Optimization размер выигрыш, %
Disabled (debug) 404480 (653824) -
Default 404480 (653824) -
Maximize speed 358912 (636416) 11,3% (4,5%)
Minimize size 348160 (624128) 13,9% (2,7%)

Компилировалась RELEASE-версия. Размер в скобках - это то же, но с включенной "Generate debug info" в релизе.

В качестве вывода - не стоит пренебрежительно относиться к стандартным средствам оптимизации. Просто не всегда им есть где "разгуляться" ;-)


 
08.05.2004
наверх