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

Просто установите FOREIGN_KEY_CHECKS до и после удаления операторов SQL.

SET FOREIGN_KEY_CHECKS = 0;
DELETE FROM table WHERE ...
DELETE FROM table WHERE ...
DELETE FROM table WHERE ...
SET FOREIGN_KEY_CHECKS = 1;

Источник: https://alvinalexander.com/blog/post/mysql/drop-mysql-tables-in-any-order-foreign-keys .

32
задан Name 5 August 2009 в 08:08
поделиться

16 ответов

Некоторые вещи, которые могут замедлить компилятор

  • Избыточные блоки в вашем предложении использует . См. этот вопрос для ссылки на CnPack .
  • Явное добавление модулей в файл проекта. Вы, кажется, уже это рассмотрели.
  • Изменены настройки компилятора, в первую очередь , включая информацию TDD32 .

Попытайтесь избавиться от неиспользуемых модулей в вашем разделе uses и посмотрите, имеет ли это значение .

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

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

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

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

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

0
ответ дан 27 November 2019 в 20:42
поделиться

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

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

1
ответ дан 27 November 2019 в 20:42
поделиться

См. это .

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

2
ответ дан 27 November 2019 в 20:42
поделиться

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

1
ответ дан 27 November 2019 в 20:42
поделиться

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

  1. Циркулярные ссылки. Джентльмен, заявивший, что это было правильно. У меня были бы определенные БОЛЬШИЕ проекты, которые компилируются быстро, и МАЛЕНЬКИЕ проекты, которые компилируются медленно. Я не мог понять этого, пока не реструктурировал код и не получил более высокую скорость компиляции. Много мелких единиц. Строить монолитные блоки несложно. Но от этого есть много штрафов.

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

2
ответ дан 27 November 2019 в 20:42
поделиться

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

3
ответ дан 27 November 2019 в 20:42
поделиться

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

  1. Похоже, в сообществе Delphi все согласны, что, если вы не хотите обновляться до последней и лучшей версии (Delphi 2007 или 2009), тогда Delphi 7 - лучший / самый быстрый / самый стабильный. Вы можете подумать об обновлении.
  2. KibitzGetOverloads звучит как что-то из компилятора kibitz - "фоновый" компилятор, который дает вам завершение кода, фоновую подсветку ошибок, всплывающие подсказки и т. Д. Похоже, вам лучше проверить вызов стек компилятора командной строки, а не IDE; вы получите что-то более полезное.
  3. Я никогда не обнаруживал, что компиляция будет быстрее после удаления DCU. DCU нужны для инкрементальной сборки, а значит, быстрее. Если ты' Чтобы увидеть более быстрые компиляции после удаления всех DCU, проверьте свое оборудование. Вы в последнее время дефрагментировали жесткий диск? Сколько свободного места у вас на диске?
4
ответ дан 27 November 2019 в 20:42
поделиться

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

5
ответ дан 27 November 2019 в 20:42
поделиться

using Delphi 7 and 2009, last week I pass from almost 2 minutes for compiling and another 45 seconds from hitting f9 and get the main form of my app to 20 seconds compiling and running. This things has drive me crazy for about 6 months and nothing I tried seems to work. Using filemon from SysInternals, I realize than every unit (mostly components) that compiler requires was searched in every folder that was in Search Path, yes, this produce a LOT of FileOpen, FileExists and FileNotFound, etc. What I do was, put every DCU, DFM, RES, etc from components all in a single folder, and having just this folder in the search path, and a couple of others folders required by the project; the results were amazing. Other problem prior to the fix, was debugging. It takes almos 40 seconds in each F7, F8 key press while debuging, this has been fixed too. Hope this info can help you. Greetings form Isla de Margarita, Venezuela. Excuse my english, if any error ;)

9
ответ дан 27 November 2019 в 20:42
поделиться

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

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

8
ответ дан 27 November 2019 в 20:42
поделиться

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

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

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

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

Это " циклическая ссылка "не дает ошибок компиляции, потому что ИСПОЛЬЗОВАНИЯ различны, но вызвала большое время компиляции.

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

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

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

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

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

Приветствую.


Neftalí -Germán Estévez-

2
ответ дан 27 November 2019 в 20:42
поделиться
2
ответ дан 27 November 2019 в 20:42
поделиться

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

1
ответ дан 27 November 2019 в 20:42
поделиться
  1. Вы установили одну папку для получения DCU. Если нет, они будут разбросаны повсюду.
  2. Поместите все модули и их неявно вызываемые модули (кроме установленных компонентов из пути к библиотеке) в dpr. Чтобы не пропустить некоторые из них, очистите путь поиска, он все равно должен скомпилироваться.
  3. После сокращения пути поиска вы можете попытаться сократить путь к библиотеке, установив компоненты в меньшее количество папок.
4
ответ дан 27 November 2019 в 20:42
поделиться

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

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

0
ответ дан 27 November 2019 в 20:42
поделиться
Другие вопросы по тегам:

Похожие вопросы: