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

используя Delphi 7 и 2009, на прошлой неделе я прохожу от 2 минут для компиляции и еще 45 секунд от удара f9 и получаю основную форму моего приложения до 20 секунд компиляции и запуска. Это привело меня в смятение около 6 месяцев, и ничто из того, что я пробовал, похоже, работает. Используя filemon из SysInternals, я понимаю, что каждый блок (в основном компоненты), который требуется для компилятора, был обыскан в каждой папке, которая находилась в пути поиска, да, это создает много файлов FileOpen, FileExists и FileNotFound и т.д. То, что я делаю, DCU, DFM, RES и т.д. Из компонентов, находящихся в одной папке, и имеющих только эту папку в пути поиска и пару других папок, необходимых для проекта; результаты были потрясающими. Другая проблема до исправления была отладкой. Требуется almos 40 секунд в каждом нажатии F7, F8 во время отладки, это тоже исправлено. Надеюсь, эта информация вам поможет. Приветствие от Isla de Margarita, Венесуэла. Извините мой английский, если есть какая-либо ошибка;)

Проверьте, нет ли путей в пути поиска, которые не находятся на вашей локальной машине.

то есть. Не связывайтесь с двоичными файлами общих сетевых ресурсов и убедитесь, что путь поиска не проверяет общие сетевые ресурсы.

Вы можете дать DelphiSpeedUp попробовать и посмотреть, не изменилось ли это. Он не ускорит компиляцию командной строки, но он утверждает, что имеет некоторые ускорения для компиляции IDE.

• Установили ли вы одну папку для получения DCU. Если нет, они будут разбросаны по всему.
• Поместите все блоки и их неявно называемые блоки (за исключением установленных компонентов из пути библиотеки) в dpr. Чтобы быть уверенным, что вы не пропустили никого, пустым поисковым путем, он все равно должен компилироваться.
• После сокращения пути поиска вы можете попытаться уменьшить путь к библиотеке, установив компоненты в меньшее количество папок.

Я не видел, чтобы компилятор со временем становился все медленнее, но мы долгое время использовали Delphi 6.

• В сообществе Delphi, как правило, сообщается, что если вы не хотите обновляться до последнего и самого большого (Delphi 2007 или 2009), то Delphi 7 является лучшим/самым быстрым/наиболее стабильным. Вы можете рассмотреть возможность обновления.
• KibitzGetOverloads звучит как что-то из компилятора kibitz - компилятор "фона", который дает вам завершение кода, подсветку фоновых ошибок, подсказки кода и т.д. Похоже, вам лучше проверить стек вызовов команды- line, а не IDE; вы получите что-то более полезное.
• Я никогда не обнаружил, что компиляции будут быстрее после удаления DCU. DCU должны сделать инкрементальную сборку, поэтому быстрее. Если вы видите более быстрые компиляции после удаления всех DCU, проверьте свое оборудование. Вы в последнее время дефрагментировали свой жесткий диск? Сколько свободного места у вас на диске?

У меня была та же проблема, и я могу придумать (2) причины, по которым это повлияло на меня.

• Циркулярные ссылки. Джентльмен, который заявил, что он был прав. У меня были бы определенные проекты LARGE, которые бы быстро компилировались, и SMALL-проекты, которые скомпилировались медленно. Не удалось понять, пока я не изменил код, а затем получил более быструю скорость компиляции. Много мелких единиц. Легко построить монолитные единицы. Но есть много штрафов.

• Я слышал это 1000 раз, развивается на медленной машине, как, например, пользователи. Эй, это для отдела тестирования. Я не могу тратить время на сбор, скорость загрузки Delphi, пакеты и т.д. Я вышел и купил компьютер "GAMERS" (WOW) с твердотельными дисками (как упоминалось ранее), 12 ГБ оперативной памяти, OVERCLOCKED "i7" чип Intel, тройные видеокарты (связанные), все на Vista64 (Vista не плохая, как только она наконец работает со всеми установленными частями). Это была настоящая боль, чтобы все было настроено. Но я больше не жду на своем компьютере. Чистая скорость компиляции, скорость загрузки и новая новая машина без всякого дерьма, установленного на последнем за последние 2 года. Я даже выгрузил DelphiSpeedUp. Он не нужен. И мне не нужно отключать AntiVirus, так как я тоже сделал это, и получил штраф за интернет-дерьмо. Таким образом AntiVirus остается включенным. Чисто и просто, получите машину BALLS OUT. Ваше время стоит больше, чем вы потратите на новый компьютер.

Несмотря на то, что частично зависит от вашего точного вопроса, я слышал, что использование твердотельного диска значительно увеличивает время компиляции с Delphi. Ник Ходжес сказал об этом сам в Delphi Podcast пару недель назад. Brian

См. this.

Я тестировал его с помощью кодовой базы VCL.NET и работал... Не знаю, остался ли он действительным для D2009, но он работал на D2006.net

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

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

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

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

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

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

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

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

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

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

Привет.

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

• U может автоматически избавиться от ненужные ссылки на единицы, что является очень эффективной оптимизацией для компиляции скорости.

• В вашей ситуации разделение проект в пакеты может улучшить скорость компиляции. Таким образом, это просто генерирует измененные пакеты, не одиночный массивный двоичный файл для каждого перекомпиляция. Работа с пакетами также может помочь в простом развертывании ваших обновлений проекта.

• Отключите ваш антивирус в реальном времени.

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

P.S. Поместите Delphi и ваш проект на твердотельный накопитель, и вы увидите увеличение скорости BIG.

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

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

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

Я использую Монитор процессов из Microsoft/SysInternals для мониторинга компилятора:

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

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

• Вид "дерева", где вы рекурсивно видите, в каком порядке компилируются единицы.
• Для каждого устройства задержка между ".PAS файлом открыта" и ".DCU файл".

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

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

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

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

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

Другие длинные снимки:

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

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