Delphi: Каковы недостатки использования неиспользуемых единиц, перечисленных в предложении использования? - PullRequest
9 голосов
/ 23 декабря 2010

Я использую cnPack Использует очиститель , но в целом, каковы недостатки наличия бесполезных юнитов?

Я знаю некоторые из них:

1) конечно, еслиединица никогда не используется во всем проекте, будет бесполезное потребление ресурсов

2) понимание кода даст бесполезные результаты

3) понимание кода будет медленнее

Но представьте себе простой случай:

  • У меня есть проект с 2 формами, я использую StrUtils в одной из них, но я объявил StrUtils в обеих из них ... Есть ли недостатки в использовании памятив этом случае или нет?

Ответы [ 3 ]

15 голосов
/ 23 декабря 2010

Нет. В общем, smartlinking работает так:

  • Если вы где-то используете юнит, то по крайней мере код инициализации и финализации связан в.
  • В принципе, только те функции / методы, которые вы фактически используете, прямо или косвенно из основной программы (.dpr), связаны в.
  • Некоторые биты, которые доступны через RTTI , также будут связаны в. Правило большого пальца заключается в том, что RTTI для перечислений всегда связывается (если вы используете перечисление), и это (как только вы создаете класс), все, что опубликовано или доступно через опубликованные свойства, связано в.
  • Имейте в виду, что инициализация неиспользуемых модулей может привести к dll или даже целым каркасам dll (таким как .NET), что может быть ненужным осложнением развертывания.
  • (Как говорит Роб в комментариях) Ресурсы - это еще один фактор, который всегда связан, так как из-за использования во время выполнения компилятор не может определить, используются они или нет.

Вывод: окончательный размер .exe определяется

  • в основном что-нибудь достижимое вышеуказанными корнями (основная программа, инициализация, финализация, RTTI классов, которые могут быть построенными),
  • некоторые биты, которые всегда связаны, если используется единица (ресурсы, определенные формы RTTI, например, перечисления),
  • языковые помощники в RTL, такие как подпрограммы помощника по аннулированию, большинство из них в System, некоторые могут быть в вариантах.
  • Относительно небольшой внутренний администратор программы (например, таблицы с блоками, определяющими порядок инициализации / финализации), таблицы, необходимые для обработки ресурсов, связывание DLL и т. Д.
  • Отладочная информация (если TD32 включен)
  • настройки компилятора , такие как оптимизация и проверки во время выполнения, также слегка влияют на размер двоичного файла.
  • Бинарное сжатие использует как UPX. Я не рекомендую , хотя, по моему опыту, они постоянно вызывают проблемы.

Free Pascal примерно работает одинаково, значения по умолчанию просто разные; Отладка в настоящее время почти всегда «в двоичном формате» (например, TD32), а в моментальных снимках smartlinking по умолчанию отключен. (хотя в официальных релизах он включен).

Кроме того, нельзя упускать из виду величину. Strutils в целом походит на 15 КБ максимум.

(обновление 2011-11-01)

Получил замечание от sb на этот ответ, которым я хотел поделиться:

По сути, он сомневается в замечании, что перечисления всегда связаны между собой. Может быть, регистрация класса, у которого есть опубликованное свойство типа перечисления, затягивает их. Рассуждения имеют смысл, но я еще не проверял это. Таким образом, RTTI enum напрямую может быть связан, только если typeinfo (tenumtype) запрашивается где-то, или если он используется в опубликованном разделе используемого класса. (напрямую или typeinfo (theclass) запрашивается)

7 голосов
/ 23 декабря 2010

Delphi smart linker игнорирует неиспользуемый код, поэтому обычно наличие этих «лишних» модулей не увеличивает размер скомпилированной программы.

Вот некоторые моменты, которые я получаю от этой ссылки о недостатках неиспользованных единиц

  1. Более чистый код для поддержки, не нужно беспокоиться о коде, который не используется
  2. Код из разделов инициализации и финализации в неиспользуемых единицах не связан в
  3. Компиляция выполняется быстрее и быстрее
5 голосов
/ 23 декабря 2010

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

Если у вас возникла проблема из-за этого, вы всегда можете полностью указать идентификатор. Мне бы очень хотелось увидеть предупреждения компилятора о том, что вы называете идентификатор, идентификатор которого определяется только этим последним объявлением в разделе использования правило определения области действия.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...