Eugene Yavorsky
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