Какие простые изменения внесли наибольшие улучшения в ваши программы на Delphi

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

• Выключите отладку

• Включите оптимизацию

• Удалите все ссылки на единицы, которые ты на самом деле не используешь

• Ищите утечки памяти

Предварительное распределение списков и массивов, а не их увеличение с каждой итерацией.

Это, вероятно, оказало на меня наибольшее влияние с точки зрения скорости.

При работе с tstringlist (или подобным) устанавливайте «sorted: = false» до тех пор, пока не понадобится (если вообще). Кажется, нетрудно ...

Разумно используйте SetLength () для строк и массивов. Оптимизируйте инициализацию с помощью FillChar или ZeroMemory.

Локальные переменные, созданные в стеке (например, типы записей), работают быстрее, чем переменные, выделенные в куче (объекты и New ()).

Используйте объекты повторно, а не уничтожайте, а затем создавайте. Но убедитесь, что код управления для этого работает быстрее, чем менеджер памяти!

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

Если вам нужно использовать Application.processmesssages (или аналогичный) в цикле, попробуйте вызывать его только каждую N-ю итерацию.

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

.BeginUpdate;

.EndUpdate;

;)

Используйте множество утверждений для отладки, а затем отключите их в коде доставки.

Отключите проверку диапазона и переполнения после тщательного тестирования.

Если вам действительно, действительно, действительно нужно быть легким, вы можете отказаться от VCL. Взгляните на KOL & MCK. Конечно, если вы это сделаете, то вы обмениваете функции на уменьшение занимаемой площади.

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

Воспользуйтесь преимуществом кода проект FastCode. Части этого были включены в собственно VCL / RTL (например, FastMM), но есть еще кое-что, что вы можете использовать!

Обратите внимание, у них есть новый сайт, они тоже перемещаются, но, похоже, он немного неактивен.

Может воспользоваться Пакет исправлений VCL от Андреас Хаусладен

The VCL Fix Pack is a Delphi unit that fixes VCL and RTL bugs at runtime by patching the original functions. If you want all IDE Fix Pack fixes in your application this unit is what you need. Adding the unit to your project (Delphi and C++Builder) automatically installs the patches that are avilable for your Delphi/C++Builder version.

Используйте инструмент профилирования Delphi (Some здесь или здесь) и обнаруживайте свои собственные узкие места. Оптимизация неправильных узких мест - пустая трата времени. Другими словами, если вы примените все эти предложения здесь, но проигнорируете тот факт, что кто-то поместил сон (1000) (или аналогичный) в какой-то очень важный код, это пустая трата вашего времени. Сначала устраните ваши настоящие узкие места.

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

Рассмотрите проблемы с оборудованием. Если вам действительно нужна производительность, подумайте, на каком жестком диске (-ах) работает ваша программа и ваши базы данных. Есть много переменных, особенно если вы работаете с базой данных. RAID - тоже не всегда лучший ответ.

1. Создать модульные тесты
2. Убедитесь, что все тесты пройдены
3. Профилируйте свое приложение
4. Рефакторинг ищет узкие места и память
5. Повторите с шага 2 (по сравнению с предыдущим проходом)

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

Вы можете посмотреть Библиотека OmniThread от Габра, но есть ряд библиотек потоков, разрабатываемых для Delphi. Вы можете легко реализовать свою собственную параллель для использования анонимных типов.

Для старой разработки BDE, когда я только начал Delphi, я использовал множество компонентов TQuery. Кто-то сказал мне использовать мастер-деталь TTable после того, как я объяснил ему, что я делаю, и это заставило программу работать намного быстрее.

Вызов DisableControls может пропустить ненужные обновления пользовательского интерфейса.

1. FastMM
2. FastCode (библиотека)
3. Используйте высокопроизводительные структуры данных, такие как хеш-таблица и т. д. Во многих местах быстрее создать один цикл, который составляет хеш-таблицу поиска для ваших данных. Использует довольно много памяти, но, безусловно, быстро. (это, возможно, самый важный, но два первых очень просты и требуют очень мало усилий)

Прежде чем что-либо делать, определите медленные части. Не трогайте рабочий код, который работает достаточно быстро.

Уменьшите количество операций с диском. Если памяти достаточно, загрузите файл полностью в ОЗУ и выполняйте все операции в памяти.

Прекратите использовать TStringList для всего.

TStringList - это нет, структура данных общего назначения для эффективного хранения и обработки всего, от простых до сложных типов. Ищите альтернативы. Я использую Библиотека контейнеров и алгоритмов Delphi (DeCAL, ранее известный как SDL). Julians EZDSL также должен быть хорошей альтернативой.

Если вы используете потоки, установите их привязку к процессору. Если вы еще не используете потоки, подумайте об их использовании или изучите асинхронный ввод-вывод (порты завершения), если ваше приложение выполняет много операций ввода-вывода.

Подумайте, действительно ли база данных СУБД - идеальный выбор. Если вы только читаете данные и никогда не меняете их, то простой файл с фиксированной записью может работать быстрее, особенно если путь к данным может быть легко отображен (например, один индекс). Тривиальный двоичный поиск по фиксированному файлу записи по-прежнему очень быстр.

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

• BeginUpdate ... EndUpdate
• ShortString против String
• Используйте массивы вместо TStrings и TList

Но печальный ответ заключается в том, что настройка и оптимизация дадут вам, возможно, 10% улучшение (и это опасно); редизайн может дать вам 90%. Как только вы действительно поймете цель, вы часто сможете переформулировать проблему (и, следовательно, решение) в гораздо лучших терминах.

Ваше здоровье

Осмотрите все шлейфы и найдите способы короткого замыкания. Если вы ищете что-то конкретное и находите это в цикле, используйте команду BREAK, чтобы немедленно выйти из строя ... нет смысла повторять цикл через все остальное. Если вы знаете, что у вас нет совпадения, используйте ПРОДОЛЖИТЬ как можно быстрее.

если вам нужно выполнить сравнение строк, используйте оптимизированные функции STRCOMP или TEXTCOMP. Для простого равенства используйте оптимизированные функции SAMESTR и SAMETEXT. Всегда выбирайте SAMESTR / STRCOMP, если вы знаете, что случай всегда будет одинаковым.

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

Хотя AsyncCalls может намного больше, я нашел его полезным для этой очень простой цели. Допустим, у вас заблокирована подпрограмма следующим образом: кнопка «Отключить», «Выполнить работу», «Включить». Вы перемещаете часть Do Work в локальную функцию (назовите ее AsyncDoWork) и добавляете четыре строки кода:

var  a: IAsyncCall;    
a := LocalAsyncCall(@AsyncDoWork);  
while (NOT a.Finished) do 
  application.ProcessMessages;  
a.Sync;

Для вас это запускает AsyncDoWork в отдельном потоке, в то время как ваш основной поток остается доступным для ответа на пользовательский интерфейс (например, перетаскивание окна или нажатие кнопки «Прервать»). Когда AsyncDoWork завершается, код продолжается. Поскольку я переместил его в локальную функцию, все локальные вары доступны, и код менять не нужно.

Это очень ограниченный тип «многопоточности». В частности, это двухпотоковая передача. Вы должны убедиться, что ваша функция Async и пользовательский интерфейс не имеют доступа к одним и тем же компонентам VCL или структурам данных. (Я отключаю все элементы управления, кроме кнопки остановки.)

Я не использую это для написания новых программ. Это просто действительно быстрый и простой способ сделать старые программы более отзывчивыми.

Если у вас есть список, используйте динамический массив чего угодно, даже следующую запись:

Для этого не нужны классы, нет освобождения, и доступ к нему очень быстрый. Даже если ему нужно вырасти, вы можете это сделать - см. Ниже. Используйте TList или TStringList, только если вам нужна большая гибкость в изменении размера.

type
  TMyRec = record
    SomeString : string;
    SomeValue : double;
  end;

var
  Data : array of TMyRec;
  I : integer;

..begin
  SetLength( Data, 100 ); // defines the length and CLEARS ALL DATA
  Data[32].SomeString := 'Hello';
  ShowMessage( Data[32] );

  // Grow the list by 1 item.
  I := Length( Data );
  SetLength( Data, I+1 );

..end;

Избегайте использования TTable с полями подстановки, когда подойдет TQuery.

У меня был отчет, который работал очень медленно в большой базе данных. Он использовал TTable с кучей полей поиска. Я повесил сетевой монитор на свое приложение и обнаружил, что огромное количество данных текло по строкам, когда я проходил через этот TTable с полями поиска. Переход на TQuery резко сократил объем трафика и существенно изменил скорость.

Этот совет на самом деле просто учит мыслить в терминах клиент-сервер.

Запустите SysInternals ProcessExplorer и FileMonitor и наблюдайте за поведением вашего приложения с точки зрения ОС. Вы найдете сюрпризы, такие как неожиданная активность диска и реестра. Если вы могли подумать, что сохраняете свои настройки в реестр или в файл .ini за одну операцию, возможно, вы выполняете 100 операций записи. Вы можете обнаружить, что для записи в базу данных требуется 30 операций записи, когда вы думали, что делаете 3. Некоторые из них можно настроить с помощью таких вещей, как транзакции и буферизация. Но не раньше, чем вы сначала найдете проблемные места. У меня было такое «пробуждение», когда я прошел сертификацию U3 для своего приложения (у накопителей SanDisk U3 есть собственная сертификация). Я никогда не зарабатывал много денег, имея версию своего приложения для U3, но упражнение того стоило.

По возможности избегайте thread.synchronize. Это останавливает все и ждет поток VCL. Мы изменили большую часть наших синхронизаций, чтобы использовать thread.queue, где они могли бы выполняться асинхронно. Здесь также помогает использование анонимных методов.