Что вызывает увеличение размера EXE в C++ Builder XE4 по сравнению с C++Builder 2010?

Я обновил проект с RAD Studio 2010 до RAD Studio XE4. В основном это C++ с использованием C++ Builder, наполовину из RAD Studio, с примесями Delphi.

До 2010 года сборка выпуска составляла 22 МБ. Под XE4 та же версия выпуска составляет 55 МБ.

Это проблема, потому что:

  • 55 МБ замечательно велика для EXE
  • Запуск программы занимает значительно больше времени (немного, но немного).
  • Многие из наших клиентов загружают новые версии из отдаленных районов или с корабля, находясь в море. Размер имеет значение.

Что может вызвать это, и как мне это исправить?

Заметки

  • Как ни странно, отладочная сборка все еще только 23 МБ. Настройки проекта кажутся очень похожими. Я просмотрел экспорт наборов опций и увидел только <UsePackages>True</UsePackages> как что-то настоящее в Release не Debug; удаление не имело никакого значения. Кроме того, включена оптимизация кода и отсутствие _DEBUG определить.
  • Отладочная информация генерируется для сборки Release, но помещается во внешний файл.tds. (Это будет использоваться для EurekaLog в будущем, и в настоящее время позволяет нам отлаживать сборки выпуска программы.) Мне было интересно, связывался ли компоновщик в отладочной информации, но насколько я знаю, компоновщик C++ всегда помещает отладочную информацию в внешний файл, который существует, плюс EurekaLog еще не включен в сборку.
  • Файлы проекта (.cbproj) были созданы в XE4, а не обновлены по сравнению со старыми файлами 2010 года. Я сделал новые проекты и добавил старые файлы.cpp и.pas. Это было сделано для того, чтобы избежать проблем, вызванных обновлением - на форумах Embarcadero часто рекомендуется создавать проекты заново при обновлении версий IDE. До этого я действительно сталкивался с меньшим количеством проблем, чем в 2010 году.
  • Существует много упоминаний о том, что EXE-файлы Delphi XE2+ заметно больше, чем те, что были созданы в старых версиях Delphi. ( 1, 2, 3, 4, 5, 6.) Хотя компоновщик C++ отличается от используемого в Delphi, возможно, причины аналогичны.
    Причина, по-видимому, в основном в том, что RTTI используется кодом RTL Delphi, который в проекте Delphi можно устранить, указав {$WEAKLINKRTTI ON}, Документация XE4 не упоминает эквивалентную прагму компоновщика C++. Есть #pragma explicit_rtti (аналог C++ {$RTTI}) а также __declspec(delphirtti) (аналог C++ {$M}/{$TYPEINFO}).
  • Проект связан с использованием пакетов времени выполнения и динамического RTL. Это 32-битное приложение VCL форм. У меня XE4 Update 1 установлен на Windows 7.
  • Изменить: David Heffernan спрашивает в комментарии ниже о размерах файлов.map каждого проекта.
    Размер выпуска.map составляет 17 МБ, а размер.tds - 80 МБ.
    Отладка теперь перестала ссылаться, так как компоновщик сообщает, что ему не хватает памяти (старая, старая ошибка, которая должна была быть исправлена ​​несколько лет назад.) Не создано ни одного файла.map или.tds, поэтому я не могу дать размер сравнения точно. Из памяти.tds был около 100 МБ, и, к сожалению, я не помню размер.map. Если я получу ссылку на проект, я обновлю вопрос.
  • Снова отредактируйте: я нашел ответ (sortof) - отключение "Развернуть встроенные функции" уменьшает размер EXE до ожидаемого значения. Это само по себе удивительно - см. Мой ответ ниже. Обратите внимание, что в отладочной сборке это уже отключено и все равно не будет связываться, что выдает ошибку нехватки памяти.
    Я еще не пометил свой ответ как правильный, в случае, если кто-то может дать некоторое представление о том, что именно происходит, что будет гораздо лучшим ответом, чем просто "отключить эту опцию".
Источник

1 ответ

Решено (sortof.)

В сборке Release была включена функция "Развернуть встроенные функции". Отключение этого уменьшило размер EXE с 55 МБ до 17 МБ.

Параметры проекта, показывающие параметр 'Развернуть встроенные функции' в разделе 'Компилятор C++ - отладка'

Это поразительная разница, и я не знаю, почему эта разница такая большая. Я считаю маловероятным, что у нас есть встроенные функции на 38 МБ, даже считая шаблоны и заголовки, не говоря уже о тех, которые используют inline ключевое слово. Если есть способ проверить шаги компоновщика, выходные данные или файлы obj, чтобы увидеть, что расширяется, пожалуйста, прокомментируйте - я нашел бы это действительно ценным.

Источник
Другие вопросы по тегам