Delphi: Как организовать исходный код для увеличения производительности компилятора?

Question

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

Кто-нибудь знает способ определить, что делает компилятор все медленнее и медленнее? Любые советы, как организовать код для улучшения производительности компилятора?

Я уже пробовал следующие вещи:

• Явно включите большинство единиц в dpr вместо того, чтобы полагаться на путь поиска: ничего не улучшилось.
• Используйте компилятор командной строки dcc32: он не быстрее.
• Попробуйте посмотреть, что делает компилятор (используя ProcessExplorer из SysInternals): по-видимому, он в большинстве случаев выполняет функцию с именем 'KibitzGetOverloads'. Но я ничего не могу сделать с этой информацией ...

РЕДАКТИРОВАТЬ, Резюме ответов до сих пор:

Ответ, который работал лучше всего в моем случае:

• Функция «Очистить ссылки на неиспользуемые единицы» из cnpack . Он почти автоматически очищал более 1000 ссылок, делая «холодную» компиляцию примерно вдвое быстрее. («холодная» компиляция = стереть все dcu файлы перед компиляцией). Получает список ссылок от компилятора. Поэтому, если у вас есть {$ IFDEF}, проверьте, что все ваши конфигурации все еще компилируются.

Следующее, что я хотел бы попробовать:

• Рефакторинг ссылок на единицы вручную (в конце концов, используя абстрактный класс) но это гораздо больше работы, так как мне сначала нужно определить, где проблемы. Некоторые инструменты, которые могут помочь:
  • GExperts добавляет браузер зависимостей проекта в Delphi IDE (но, к сожалению, он не может отображать размер каждой ветви)
  • Delphi Unit Dependency Viewer V1.0 делает то же самое, но без Delphi. Может вычислять простую статистику (на какие единицы больше всего ссылаются, ...)
  • Икар , на который ссылается ссылка в одном из ответов.

Вещи, которые ничего не изменили в моем случае:

• Размещение всех файлов из моей программы и всех компонентов в одной папке без подпапок.
• Дефрагментация диска (я пробовал с ramdisk)
• Использование виртуального диска для папок с исходным кодом и выходными файлами.
• Отключение антивируса сканирования в реальном времени
• Перечисление всех модулей в файле dpr вместо использования пути поиска.
• Использование компилятора командной строки dcc32 или ecc32.

Вещи, которые не относятся к моему делу:

• Как избежать зависимости от общих сетевых ресурсов.
• Использование DelphiSpeedUp , потому что оно у меня уже было.
• Использование одной папки для всех dcu (я всегда так делаю)

Вещи, которые я не пробовал:

• Обновление до другой версии Delphi.
• Использование dcc32speed.exe
• Использование твердотельного накопителя (я не пробовал, но я пытался с виртуальным диском, куда я помещал весь исходный код. Но, возможно, я должен был также установить delphi на виртуальный диск)

Answer 1

У нас была такая же (или похожая) проблема. У нашего пакета есть время компиляции около 12 мин. После изменений теперь мы перешли на 32 сг.

После многих испытаний мы обнаружили, что «проблемная ситуация» была следующей: В одной упаковке:

• Устройство A использует большое количество устройств: U1, U2, U3, U4, ... U100 (использование интерфейса) в одном пакете. Это важная единица, которая централизует всю работу по инициализации.

• Все единицы пакета, U1, U2, U3, .., U100 использует Единица A (использование реализации)

Эта "циклическая ссылка" не дает ошибок компиляции, потому что USES отличаются, но вызвала большое время компиляции.

РЕШЕНИЕ: Исключите ссылку на каждое устройство, U1, U2, U3, ...., U100 в A Unit .

Теперь Единица использует большое количество единиц: U1, U2, ...., U100, но единицы U1, U2, ..., U100 не используют единицу A .

После этого изменения время компиляции резко сократилось.

Если у вас похожая ситуация, вы можете попробовать это.

Извините за мой плохой английский.

Привет.

---

Нефтали-Герман Эстевес-

Answer 2

Поскольку я не набрал 50 очков репутации, я не могу ответить на мой пост BALLS OUT. Поэтому я должен начать новую позицию здесь. Я купил машину для работы с очень большими файлами Photoshop, а также много занимаюсь 3D-моделированием в Inventor и 3DStudio MAX. Вот почему я купил новую машину. НО ... Я определенно получил огромное увеличение в моем использовании Delphi из-за этого. Моя зарплата стоит намного больше, чем 2 КБ, которые я потратил на новую машину, в отличие от покупки некоторого базового Dell (что может быть хорошо для Delphi). Так что любой BOOST, который я могу получить, это БОНУС. Если вы выполняете эту работу весь день, каждый день, как я, любая задержка, с которой вы сталкиваетесь, начинает становиться настоящей проблемой. Что он сделал для меня с помощью Photoshop, продуктов Autodesk и DELPHI. Так что я скажу это снова, новая машина BALLS OUT, улучшит вашу производительность. Парень спрашивал, что он может сделать, чтобы улучшить производительность компиляции. Итак, я высказал свое мнение.

P.S. Поместите Delphi и ваш проект на твердотельный накопитель, и вы увидите БОЛЬШОЕ улучшение скорости.

Answer 3

Компилятор будет компилировать только измененные модули. Если вы изменили код в разделе интерфейса, все модули, которые зависят от измененного модуля, компилируются. Если будет изменен только код в разделе реализации, компиляция будет только этим модулем, но предположительно свяжет все модули. Подразумевает хороший дизайн интерфейсов, но если вы реструктурируете код, чтобы ограничить изменения во времени реализации, время компиляции может сократиться. Я понятия не имею, насколько. Этот факт упоминается в файлах справки Delphi в разделе Множественные и косвенные ссылки на модули в Delphi 7 «Использование Delphi».

Answer 4

Попробуйте установить ram-диск и указать путь вывода dcu, чтобы он там указывал. Это более чем вдвое сократило время компиляции с Delphi 2007 поверх DelphiSpeedUp.

Answer 5

Несколько лет спустя я снова борюсь с увеличением времени компиляции. Я в настоящее время использую Delphi XE4, и я нахожусь в точке, где мне абсолютно необходимо рефакторинг ссылок на единицы. Я подумал о новом способе определения проблем:

Я использую Process Monitor от Microsoft / SysInternals для мониторинга компилятора:

1. Я запускаю Process Monitor с фильтром, показывающим только dcc32.exe (или bds.exe при работе из IDE).
2. Я строю свой проект из командной строки.
3. В конце я смотрю на операции CreateFile в журнале Process Monitor.

Для каждого модуля есть запись для файла .PAS (когда компилятор начинает работать на этом модуле) и запись для файла .DCU (когда компилятор комплексно выполняется с этим модулем). Работая с журналом в текстовом редакторе и / или в Excel, я могу извлечь такую ​​информацию:

• Некое «дерево», где вы рекурсивно видите, в каком порядке были скомпилированы модули.
• Для каждого блока задержка между «.PAS файл открыт» и «.DCU файл записан».

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

Answer 6

Что я делаю, так это всегда проверяю, чтобы в пути к библиотеке было очень мало каталогов, а также большинство компонентов и статический код. Я также проверяю, чтобы исходный код НЕТ был доступен в пути к библиотеке, только .dcu / .res и т. Д. Только исходный код browsepath имеет исходный код, а особые обстоятельства обрабатываются через путь поиска для проекта.

Просто ограничьте то, что вы компилируете в любой ситуации.

Answer 7

• Не компилировать на сетевых дисках. Время поиска значительно хуже.
• Рассмотрите возможность указания вашей директории dcu ("unit output") на ramdrive.
• Ограничить количество каталогов include / unit.
• Старайтесь избегать незначительных циклических ссылок, которые по-прежнему принимает компилятор, особенно для больших блоков (например, сгенерированных блоков ORM для вашего OPF). Это может привести к тому, что большие модули будут скомпилированы дважды. (Delphi допускает незначительные взаимные рассылки или это только функция FPC?)

Я никогда не пробовал, но жесткое кодирование всех файлов с полным / относительным путем в центральном .dpr также может помочь (сценарий для регенерации / обновления?). (Вы упомянули это выше, но было ли это с путем xx в нотации \ path \ yyy?).

Другие длинные выстрелы:

• Использовать Kylix (мой ввод / вывод file / dir в Linux значительно лучше в моем опыте (хотя это из опыта FPC)). Может быть, нам нужен обратный крестикликс: -)
• Используйте отдельную (Windows) машину для сборки и настройте NTFS поверх реестра, чтобы сделать его менее «безопасным». (что вас не волнует, так как все это система ревизий для начала). Afaik эти параметры могут быть сделаны глобальными только для всех файловых систем, следовательно, для отдельной системы. Добавьте к нему рейдовый массив или Raptor.
• Забудьте о твердом состоянии. Хороший гудок, но высокий коэффициент записи в конечном итоге убьет его (как ресурс, так и производительность, когда он станет полнее и не сможет больше оптимально распределяться), и вам нужны дорогие Intel, чтобы превзойти два HD за $ 75 в RAID.

P.s. Извините за ссылки FPC. Я делаю и то, и другое, и я иногда больше не знаю, что к чему.