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

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

Я уже не раз приводил пример из своей практики и приведу его еще раз Когда я в 1995 году пытался написать собственный движок трехмерного мира (набор функций для прорисовки графики игры) под DOS (в стиле Doom), то он у меня получился слишком медленным. Долгие оптимизации ни к чему не приводили, и перемещение по-прежнему происходило с задержками даже на довольно мощном для того времени компьютере Pentium 100 с 32 Мбайт памяти. При этом мир состоял только из стен, "обтянутых" текстурами, без артефактов и противников.

Я потратил около месяца на "вылизывание" каждой строчки кода, но эффект был минимален. Тогда я остановился и стал реально оценивать слабые места. Расчет сцены происходил быстро, а самым медленным был именно вывод на экран. В MS-DOS его можно было осуществить с помощью прерываний, прямого доступа к памяти и переключения страниц в совокупности с прямым доступом к памяти. Я использовал второй способ, а про третий даже не знал. Тогда мне на глаза попалась статья на английском языке, где описывался пример переключения активной видеостраницы. Я реализовал это на языке С, и скорость вывода улучшилась.

Расчет сцены занимал намного меньше времени, чем видеовывод. Копирование в видеопамять происходило побайтно, а так как данных было достаточно, то процесс отнимал много времени. После того как я переписал вывод на экран на ассемблере и сделал копирование данных в видеобуфер сразу по два слова или 4 байта (DWORD), мой мир "забегал, как сумасшедший".

Я понял, что оптимизация очень сложный процесс, и пока я ею занимался, у меня пропало стремление создавать какую-то игру. Стало понятно, что тренировка знаний прошла успешно, но создавать коммерческий продукт в одиночку, в то время, когда все переходили на Windows, было глупо. Вот так мой проект и остался лежать на запыленной полке в архиве на одной из "болванок". Зато я приобрел хороший опыт, и если вы хотите потренироваться в оптимизации, то советую поработать с графикой. Именно здесь скорость вывода сложных сцен на экран монитора в реальном времени встает на первое место.

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

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

2.4. Инициализация || Оглавление || 2.6. Оптимизация циклов


Delphi в шутку и всерьез: что умеют хакеры



Новости за месяц

  • Декабрь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31