Почему скорость компиляции Delphi ухудшается, чем дольше он открыт, и что я могу с этим поделать?

Question

Почему скорость компиляции Delphi ухудшается, чем дольше он открыт, и что я могу с этим поделать?

34

Моя компания работает над большим проектом на Delphi уже более десяти лет. Наша кодовая база растет с годами и теперь насчитывает около 4 миллионов строк кода. Скорость компиляции становится проблемой. Мы потратили время, затрачивая единичные круговые ссылки (известная причина медленной компиляции) и изучали каждый аспект установки. Это доходит до того, что мы не сможем существенно улучшить его с помощью того, что мы можем контролировать.

В настоящий момент на современном ПК с 4 ядрами под управлением Windows XP SP3 и Delphi 2006, запустите Delphi и сделайте полную сборку, это займет ~ 40 секунд. Затем, если мы сделаем еще одну полную сборку в той же самой сессии Delphi, это займет 1 м 40 секунд. Повторите еще одну полную сборку, это будет еще хуже. Итак, и т.д.

(Мы хорошо знаем, что сама Windows кэширует файлы, и это сильно влияет на скорость компиляции. Вышеприведенные цифры основаны на том, что файлы кэшируются. Мы создали такой сценарий, получив Delphi для компиляции проекта один раз, завершая он, а затем запускает новую сессию Delphi, поэтому, хотя 40 секунд не выглядит медленным, это происходит только из-за того, что файлы кэшируются Windows. И мы делаем это, чтобы сравнить apple-to-apple.)

Что нас беспокоит, почему скорость компиляции ухудшается. (Мы наблюдали, что в прошлом замедление было хуже, если в проекте было много единичных круговых ссылок.) Если мы закончим Delphi и начнем новую сессию, время компиляции вернется к 40 секундам. Еще более интересная вещь, которую мы наблюдаем, заключается в том, что мы можем добиться "улучшения" с той же скоростью, нажав кнопку "Отмена", чтобы прервать компиляцию, а затем выполнить полную сборку сразу. Время компиляции также вернется к 40 секундам.

Нам кажется, что собственный кеш-память Delphi не зависит от сборки, но с течением времени ухудшается. И также появляется кнопка "Отмена", которая как-то очищает этот кеш. Мы думаем, что если мы сможем подключиться к подсистеме IDE Delphi, которая выполняет эту очистку, мы всегда можем поддерживать скорость компиляции с максимальной производительностью. Но мы не знаем, как.

Кто-нибудь знает, что мы можем сделать?

Мы по-прежнему используем Delphi 2006, поскольку мы еще не нашли способ переноса нашего большого проекта в Unicode. Я читал на форумах, что последний Delphi XE демонстрирует аналогичную скорость компиляции с единичной циклической ссылкой. Кто-нибудь знает, решила ли Delphi XE проблему?

p.s. Мы также знаем, что разделение проекта на пакеты времени выполнения может сократить время компиляции. Но для развертывания и административных причин мы стараемся избегать использования пакетов времени выполнения.

John 05 июль 2011, в 03:43

Источник

3

Вы исключили антивирусное программное обеспечение, программное обеспечение для индексирования и сторонних экспертов, работающих в IDE?
Cosmin Prund 05 июль 2011, в 04:45
8

Вы рассматривали компилятор командной строки?
J-16 SDiZ 05 июль 2011, в 05:10
8

andy.jgknet.de/blog/ide-tools/delphispeedup
RobertFrank 05 июль 2011, в 05:17
1

Что касается отсеивания ссылок на единицы, вы делали это вручную? Если это так, вы должны попробовать CnPack's Uses Cleaner. (У меня не было проблем с этим, но резервное копирование ваших файлов перед запуском не повредит)
Lieven Keersmaekers 05 июль 2011, в 06:11
1

@ J-16 Компилятор командной строки работает медленнее, чем IDE-компилятор, по крайней мере, в большинстве версий Delphi, если только вы не используете какой-то особый способ ускорения, например andy.jgknet.de/blog/ide-tools/dcc32speed-12
Arnaud Bouchez 05 июль 2011, в 06:13
0

@Lieven Вы уверены, что более чистое предложение «использует» сделает компиляцию быстрее? Если некоторые модули вообще не используются, он скомпилирует меньше строк кода, поэтому будет быстрее. Но если единицы измерения просто помечены в разделе «использует», не используются в этом модуле, но используются в другом модуле, это не будет иметь никакого значения ИМХО.
Arnaud Bouchez 05 июль 2011, в 06:15
0

@ A.Bouchez - нет, не уверен, но его случай не мешает попробовать .
Lieven Keersmaekers 05 июль 2011, в 06:36
3

Обратите внимание, что «современный ПК с 4 ядрами» здесь не особо помогает. Компилятор Delphi будет использовать только одно ядро, поэтому вам лучше использовать более быстрые ядра. то есть, при прочих равных, возьмите двойные 3,33 ГГц по сравнению с Quad 1,8 ГГц.
Chris Thornton 05 июль 2011, в 11:50
0

Вы пробовали SSD жесткий диск?
Harriv 05 июль 2011, в 18:11
0

@Lieven - Мы делали ссылки на круговые единицы вручную. Мы пробовали некоторые инструменты раньше, но это не сработало. Я полагаю, что это было потому, что проект был слишком велик для инструментов. Но мы не пробовали CnPack. Я взгляну. Спасибо!
John 06 июль 2011, в 01:34
0

@ Джон, это имело большое значение в прошлом. Ищите здесь ссылку (и бесстыдный плагин) stackoverflow.com/questions/920560/…
Lieven Keersmaekers 06 июль 2011, в 06:32
0

В Delphi XE все еще есть эта ошибка. Что я делаю, я перезапускаю IDE каждые 20 минут (всякий раз, когда я проверяю свою электронную почту, делаю перерыв и т. Д.).
Rigel 10 май 2014, в 07:43
0

@ChrisThornton - это правда, но если у вас многоядерная система, другие программы будут работать на дополнительных ядрах, оставляя (надеюсь) свободное ядро для Delphi.
Rigel 10 май 2014, в 10:48

Показать ещё 11 комментариев

Теги:

performance

delphi

compilation

6 ответов

17

Постепенное снижение производительности может быть связано с утечкой памяти или другой ошибкой в компиляторе. Небеса знают, что D2005 и D2006 их хватит! Если вы не можете перейти на версию Delphi с поддержкой Unicode, вы должны, по крайней мере, обновить D2007 (что, я считаю, все еще доступно для Embarcadero) для лучшей стабильности.

Кроме того, как отметил Роберт Фрэнк в комментарии, ознакомьтесь с инструментами Андреаса Хаусадена. Всего несколько дней назад он выпустил патч, который немного улучшил скорость компиляции. К сожалению, эта особенность, по-видимому, только для D2009 и более поздних версий, но многие его исправления помогают ускорить различные вещи, включая компилятор.

Mason Wheeler 05 июль 2011, в 06:20

0

Я подозреваю, что это так. Я бы порекомендовал использовать Process Explorer из SysInternals, чтобы увидеть, увеличивается ли использование памяти bds.exe при каждой компиляции проекта. Это подтвердило бы теорию утечки памяти.
Chris Thornton 05 июль 2011, в 12:55
0

Больше похоже на «теорию заговора утечки памяти». Если у вас достаточно оперативной памяти, потребуется некоторое время, прежде чем IDE начнет переключаться на диск.
Arnaud Bouchez 05 июль 2011, в 13:52

7

Хорошо стоит попробовать DelphiSpeedUp от Andreas Hausladen, но это поможет только производительности IDE, а не компиляции, как я ее понимаю.

Другая идея, которую никто еще не предложил, - использовать твердотельные диски высокой спецификации.

Я рекомендую использовать 64-битную Windows 7 с большим объемом оперативной памяти для лучшей производительности кэширования файлов.

Просто будьте благодарны, что ваш проект не написан на С++!

David Heffernan 05 июль 2011, в 07:06

1

+ для 64-битной Win7, потому что 4-ядерная система Windows XP, как упоминалось в OP, не является современной, не сегодня! Но я не очень уверен насчет этих высокопроизводительных твердотельных дисков: ОП говорит, что заставляет Windows кэшировать все файлы перед тем, как приступить к реальной сборке. Я не уверен, что лучше I / O ускорит процесс.
Cosmin Prund 05 июль 2011, в 06:43
0

@cosmin комментарии кеширования в посте делают тесты более повторяемыми. Достойный ввод-вывод уменьшит эффект кэширования. 64-битная Win 7, скажем, 16 ГБ оперативной памяти приведет к большой файловый кеш тоже.
David Heffernan 05 июль 2011, в 06:53
0

AFAIK DelphiSpeedUp изменяет низкоуровневые функции RTL за счет более быстрой реализации, включая использование GetFileAttributesEx вместо гораздо более медленного API FindFirstFile / FindClose.
Arnaud Bouchez 05 июль 2011, в 07:52
0

@ A.Bouchez Компилятор Delphi написан на C и, насколько я знаю, не использует RTL.
David Heffernan 05 июль 2011, в 07:55
2

+1 за твердотельный диск. Я использую новую машину с 300G Crucial SSD и 1 ТБ WD HD в 64-битной версии W7. Все работающие проекты Delphi расположены и построены на SSD. 1 миллион строк кода создается впервые в D7 и XE в 11 секунд, второй раз в 8 секунд. Скорость передачи SSD составляет 200-300 МБ / с по сравнению с 40 ТБ / с диска 1 ТБ.
Brian Frost 05 июль 2011, в 11:27
3

@ Брайан Я не думаю, что скорость передачи является ключевым фактором здесь, скорее, задержка начала передачи.
David Heffernan 05 июль 2011, в 11:36
2

@ Давид Я говорил о C RTL, который также был взломан Андреасом. Он не только исправил часть IDE. Посмотрите, например, что он сделал с плохим нежелательным компилятором командной строки: andy.jgknet.de/blog/ide-tools/dcc32speed-12
Arnaud Bouchez 05 июль 2011, в 13:49
1

@David Heffernan - Хотя использование твердотельных накопителей не решает проблему с постепенным снижением скорости компиляции (основная проблема, которую мы имеем), мы рассматриваем его как параллельное решение для ускорения компиляции (когда файлы pas не находятся в Кеш винды). Благодарю.
John 06 июль 2011, в 01:57

Показать ещё 6 комментариев

1

Подумайте о создании со встроенными пакетами времени, а затем создайте монолитные исполняемые файлы при отправке кода в отдел QA или распространяйте ваше приложение.

Это требует дополнительного обслуживания, но значительное увеличение времени сборки стоит того, чтобы ИМО.

У нас есть проект 2.4 MLOC с примерно 40-50 меньшими, поддерживающими приложениями. При компиляции с группой пакетов времени выполнения проект строится примерно на 500 тыс. Строк и строит примерно в 6 раз быстрее (15 секунд против 90 секунд). Многие из небольших приложений собираются за одну секунду или меньше, потому что большая часть упакованного кода является общей.

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

David Robb 06 июль 2011, в 00:06

0

Мы рассмотрели то, что вы предложили. Но мы все еще не уверены, перевешивают ли накладные расходы и риски выгоду.
John 06 июль 2011, в 01:50
0

Это понятно, и я согласен. Особенно сложно поддерживать двойные компиляции. Конфигурации сборки очень помогают. Есть еще одно потенциальное преимущество, о котором я не упомянул ранее: поскольку пакеты не могут рекурсивно зависеть друг от друга, пакетные сборки обеспечивают хороший уровень программного обеспечения. Например, код низкого уровня не может быть статически связан с кодом более высокого уровня. Это само по себе является причиной, по крайней мере, для организации кода в пакеты времени выполнения.
David Robb 06 июль 2011, в 15:30

0

В этом question есть еще несколько советов, чтобы получить лучшую скорость компиляции. Избегание циклических ссылок и обнаружение неиспользуемых единиц (с помощью CnWizards) имеют больший эффект.

Fabricio Araujo 05 июль 2011, в 21:10

0

Вы пытались скомпилировать код с помощью командной строки script?

Перекомпилировалась ли из командной строки процесс стоя на 40 секунд?

запустите из cmd "dcc32.exe", чтобы увидеть использование.

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

none 05 июль 2011, в 13:34

0

На практике я обнаружил, что компилятор командной строки работает медленнее, чем компилятор IDE, по крайней мере, в большинстве версий Delphi, если только вы не используете какой-то конкретный способ ускорения, такой как andy.jgknet.de/blog/ide-tools/dcc32speed-12
Arnaud Bouchez 05 июль 2011, в 12:24
1

Мы используем командную строку для окончательной сборки для производственного развертывания. Да, это дает довольно стабильное время компиляции 40 секунд. Но не потеряете ли вы отладку в IDE? (Я не знаю, есть ли у нас взломы. Мне нужно уточнить у моего коллеги, чтобы узнать.)
John 06 июль 2011, в 01:54

Ещё вопросы

Вы исключили антивирусное программное обеспечение, программное обеспечение для индексирования и сторонних экспертов, работающих в IDE?
Вы рассматривали компилятор командной строки?
Что касается отсеивания ссылок на единицы, вы делали это вручную? Если это так, вы должны попробовать CnPack's Uses Cleaner. (У меня не было проблем с этим, но резервное копирование ваших файлов перед запуском не повредит)
@ J-16 Компилятор командной строки работает медленнее, чем IDE-компилятор, по крайней мере, в большинстве версий Delphi, если только вы не используете какой-то особый способ ускорения, например andy.jgknet.de/blog/ide-tools/dcc32speed-12
@Lieven Вы уверены, что более чистое предложение «использует» сделает компиляцию быстрее? Если некоторые модули вообще не используются, он скомпилирует меньше строк кода, поэтому будет быстрее. Но если единицы измерения просто помечены в разделе «использует», не используются в этом модуле, но используются в другом модуле, это не будет иметь никакого значения ИМХО.
@ A.Bouchez - нет, не уверен, но его случай не мешает попробовать .
Обратите внимание, что «современный ПК с 4 ядрами» здесь не особо помогает. Компилятор Delphi будет использовать только одно ядро, поэтому вам лучше использовать более быстрые ядра. то есть, при прочих равных, возьмите двойные 3,33 ГГц по сравнению с Quad 1,8 ГГц.
@Lieven - Мы делали ссылки на круговые единицы вручную. Мы пробовали некоторые инструменты раньше, но это не сработало. Я полагаю, что это было потому, что проект был слишком велик для инструментов. Но мы не пробовали CnPack. Я взгляну. Спасибо!
@ Джон, это имело большое значение в прошлом. Ищите здесь ссылку (и бесстыдный плагин) stackoverflow.com/questions/920560/…
В Delphi XE все еще есть эта ошибка. Что я делаю, я перезапускаю IDE каждые 20 минут (всякий раз, когда я проверяю свою электронную почту, делаю перерыв и т. Д.).
@ChrisThornton - это правда, но если у вас многоядерная система, другие программы будут работать на дополнительных ядрах, оставляя (надеюсь) свободное ядро для Delphi.
Я подозреваю, что это так. Я бы порекомендовал использовать Process Explorer из SysInternals, чтобы увидеть, увеличивается ли использование памяти bds.exe при каждой компиляции проекта. Это подтвердило бы теорию утечки памяти.
Больше похоже на «теорию заговора утечки памяти». Если у вас достаточно оперативной памяти, потребуется некоторое время, прежде чем IDE начнет переключаться на диск.
+ для 64-битной Win7, потому что 4-ядерная система Windows XP, как упоминалось в OP, не является современной, не сегодня! Но я не очень уверен насчет этих высокопроизводительных твердотельных дисков: ОП говорит, что заставляет Windows кэшировать все файлы перед тем, как приступить к реальной сборке. Я не уверен, что лучше I / O ускорит процесс.
@cosmin комментарии кеширования в посте делают тесты более повторяемыми. Достойный ввод-вывод уменьшит эффект кэширования. 64-битная Win 7, скажем, 16 ГБ оперативной памяти приведет к большой файловый кеш тоже.
AFAIK DelphiSpeedUp изменяет низкоуровневые функции RTL за счет более быстрой реализации, включая использование GetFileAttributesEx вместо гораздо более медленного API FindFirstFile / FindClose.
@ A.Bouchez Компилятор Delphi написан на C и, насколько я знаю, не использует RTL.
+1 за твердотельный диск. Я использую новую машину с 300G Crucial SSD и 1 ТБ WD HD в 64-битной версии W7. Все работающие проекты Delphi расположены и построены на SSD. 1 миллион строк кода создается впервые в D7 и XE в 11 секунд, второй раз в 8 секунд. Скорость передачи SSD составляет 200-300 МБ / с по сравнению с 40 ТБ / с диска 1 ТБ.
@ Брайан Я не думаю, что скорость передачи является ключевым фактором здесь, скорее, задержка начала передачи.
@ Давид Я говорил о C RTL, который также был взломан Андреасом. Он не только исправил часть IDE. Посмотрите, например, что он сделал с плохим нежелательным компилятором командной строки: andy.jgknet.de/blog/ide-tools/dcc32speed-12
@David Heffernan - Хотя использование твердотельных накопителей не решает проблему с постепенным снижением скорости компиляции (основная проблема, которую мы имеем), мы рассматриваем его как параллельное решение для ускорения компиляции (когда файлы pas не находятся в Кеш винды). Благодарю.
Мы рассмотрели то, что вы предложили. Но мы все еще не уверены, перевешивают ли накладные расходы и риски выгоду.
Это понятно, и я согласен. Особенно сложно поддерживать двойные компиляции. Конфигурации сборки очень помогают. Есть еще одно потенциальное преимущество, о котором я не упомянул ранее: поскольку пакеты не могут рекурсивно зависеть друг от друга, пакетные сборки обеспечивают хороший уровень программного обеспечения. Например, код низкого уровня не может быть статически связан с кодом более высокого уровня. Это само по себе является причиной, по крайней мере, для организации кода в пакеты времени выполнения.
На практике я обнаружил, что компилятор командной строки работает медленнее, чем компилятор IDE, по крайней мере, в большинстве версий Delphi, если только вы не используете какой-то конкретный способ ускорения, такой как andy.jgknet.de/blog/ide-tools/dcc32speed-12
Мы используем командную строку для окончательной сборки для производственного развертывания. Да, это дает довольно стабильное время компиляции 40 секунд. Но не потеряете ли вы отладку в IDE? (Я не знаю, есть ли у нас взломы. Мне нужно уточнить у моего коллеги, чтобы узнать.)

Arnaud Bouchez · Accepted Answer · 2011-07-05T06-54-00.000Z

Если вы создаете приложение, вот несколько приемов для ускорения процесса:

Удалите все *.dcu перед сборкой (del *.dcu /s);
Запустите хороший дефрагментатор на вашем соответствующем жестком диске;
Поместите большую часть ваших исходных файлов в один и тот же каталог и попытайтесь как можно короче оставить пути библиотеки IDE и Project, с наиболее используемыми вначале элементами;
Установите DelphiSpeedUp.

Delphi 2007 должен компилироваться быстрее, чем Delphi 2006.

Delphi 2009/2010/XE, вероятно, будет медленнее: из пользовательского эксперимента реализация дженериков и нового RTTI сделала процесс компиляции более сложным, и фактическая реализация оказалась более медленной, например. чем с Delphi 2007.

Update:

Вы пытались включить запись скрытого меню ProjectClearUnitCacheItem?

У меня эта запись включена либо CnPack, либо DDevExtension (я не знаю, кто это делает, возможно позже). Это можно использовать для очистки внутреннего блока.

+ за использование хорошего дефрагментатора
@ A.Bouchez Что такое кеш модуля и какие преимущества дает его очистка?
@David Я использовал это, например, когда взломал исходный код VCL, для synopse.info/forum/viewforum.php?id=6 Компилятор поддерживает внутренний кеш для dcus. Для части VCL, если вы измените исходный код VCL, вам придется выйти, а затем ввести IDE, чтобы изменения учитывались при следующей сборке. Но это, возможно, решит проблему OP, так как кажется, что это проблема с производительностью в том же сеансе IDE. Так как он работал для меня, как замена IDE, выход / перезапуск, это может быть то же самое для Джона.
Для OP: если щелкнуть «Очистить кэш модуля», а затем «Построить», чтобы сделать сборку снова быстрой, вы можете написать небольшого эксперта, который установит там «Очистить кэш модуля + Сборка», который автоматически выполнит оба действия.
@ A.Bouchez ДА! Скрытый пункт меню «Очистить кэш модуля» делает свое дело! Это возвращает время компиляции к начальным 40 секундам. Отлично! Благодарю. (Кстати, Delphi потребовалось 8 секунд, чтобы очистить кэш модуля. Интересно, что диспетчер задач не показывал никаких изменений в использовании памяти.)
@Джон Счастлив, что вы нашли свой путь. Поэтому у меня была проблема не с памятью или скоростью, а с внутренней структурой кеша, которая не масштабируется, как ожидается, когда задействовано много модулей. Какой-то алгоритм O (n²) (например, вложенные циклы) должен использоваться внутри и не может масштабироваться, как ожидается. Возможно, стоит создать КК, если он все еще есть в Delphi XE. ;)
+1 Спасибо, это помогло мне решить мою проблему тоже!