Высокая производительность Delphi (черновик перевода глав 1-2) [Примож Габриэльчич] (fb2) читать постранично, страница - 5

poor Mr. Smith is unable to resize it, which makes him unhappy.

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

In this example, Mr. Smith simply expects that the application's user interface will respond to his commands. He doesn't care if the application takes some time to find the next move, as long as he can do with the application what he wants to. In other words, he wants a user interface that doesn't block.

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

Различные типы скорости

It is obvious from the previous example that we don't always mean the same thing when we talk about a program's speed. There is a real speed, as in the database example, and there is a perceived speed, hinted at in the document editor and game scenario. Sometimes we don't need to improve the program speed at all. We just have to make it not stutter while working (by making the user interface responsive at all times) and users will be happy.

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

We will deal with two types of performance in this book:

В этой книге мы рассмотрим два типа производительности:

Programs that react quickly to user input

Программы, которые быстро реагируют на ввод данных пользователем

Programs that perform computations quickly

Программы, которые быстро выполняют вычисления

As you'll see, the techniques to achieve the former and the latter are somehow different. To make a program react quickly, we can sometimes just put a long operation (as was the calculation of the next move in the fictitious game) into a background thread. The code will still run as long as in the original version but the user interface won't be blocked and everybody will be happy.

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

To speed up a program (which can also help with a slowly-reacting user interface), we can use different techniques, from changing the algorithm to changing the code so that it will use more than one CPU at once to using a hand-optimized version, either written by us or imported from an external library.

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

To do anything, we have to know which part of the code is causing a problem. If we are dealing with a big legacy program, problematic part may be hard to find. In the rest of this chapter, we will look at different ways to locate such code. We'll start by taking an educated guess and then we'll improve that by measuring the code speed, first by using home-grown tools and then with a few different open source and commercial programs.

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

Сложность алгоритма

Before we start with the dirty (and fun) job of improving program speed, I'd like to present a bit of computer science theory, namely the Big O notation.

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

You don't have to worry, I will not use pages of mathematical formulas and talk about infinitesimal asymptotics. Instead, I will just present the essence of the Big O notation, the parts that are important to every programmer.

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