25.3. Где искать жир и патоку?

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

Частые причины снижения эффективности

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

Вот результаты сравнения эффективности случайного доступа к элементам 100-элементного массива «в памяти» и записям аналогичного файла, хранящегося на диске:

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

Результаты аналогичного тестирования последовательного доступа к данным похожи:

Время обработки Время обработки Экономия Соотношение Язык внешнего файла данных «в памяти» времени быстродействия

С++ 3,29 0,021 99% 150:1

С* 2,60 0,030 99% 85:1

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

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

Время обработки Время обработки Экономия Язык локального файла файла по сети времени

С++ 6,04 6,64 -10%

С* 12,8 14,1 -10%

Конечно, эти результаты сильно зависят от скорости сети, объема трафика, расстояния между компьютером и сетевым диском, производительности сетевого и локального дисков, фазы Луны и других факторов.

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

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

Пример цикла инициализации, вызывающего много страничных ошибок (Java)

for ( column = 0; column < MAX COLUMNS; column++ ) { for ( row = 0; row < MAX ROWS; row++ ) {

table[ row ][ column ] = BlankTableElement();

Это хорошо отформатированный цикл с удачными именами переменных, так в чем же проблема? Проблема в том, что каждая строка (row) массива table содержит около 4000 байт. Если массив включает слишком много строк, то при каждом обращении к новой строке ОС должна будет заменить страницы памяти. В предыдущем фрагменте изменение номера строки, а значит, и подкачка новой страницы с диска выполняются при каждой итерации внутреннего цикла.

Программист реорганизовал цикл:

Пример цикла инициализации, вызывающего немного страничных ошибок (Java)

for ( row = 0; row < MAX ROWS; row++ ) {

for ( column = 0; column < MAX COLUMNS; column++ ) { table[ row ][ column ] = BlankTableElement();

Этот код также вызывает страничную ошибку при каждом изменении номера строки, но это происходит только MAX ROWS раз, а не MAX ROWS * MAX COLUMNS раз.

Степень снижения быстродействия кода из-за замещения страниц во многом зависит от объема памяти. На компьютере с небольшим объемом памяти второй фрагмент кода выполнялся примерно в 1000 раз быстрее, чем первый. При наличии большего объема памяти различие было всего лишь двукратным и было заметно лишь при очень больших значениях MAX ROWS и MAXCOLUMNS.

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

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

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

Избегайте вызовов системных методов.

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

В программе, про оптимизацию которой я рассказал в подразделе «Когда выполнять оптимизацию?» раздела 25.2, использовался кягсс AppTime, производный от коммерческого класса BaseTime (имена изменены). Объекты АррТгте использовались в программе на каждом шагу и исчислялись десятками тысяч. Через несколько месяцев мы обнаружили, что объекты BaseTime инициализировались в конструкторе значением системного времени. В нашей программе системное время не играло никакой роли, а это означало, что мы без надобности генерировали тысячи системных вызовов. Простое переопределение конструктора Knicci BaseTime так, чтобы поле time инициализировалось нулем, дало нам такое же повышение производительности, что и все остальные изменения, вместе взятые.

Интерпретируемые языки При выполнении интерпретируемого кода каждая команда должна быть обработана и преобразована в машинный код, поэтому интерпретируемые языки обычно гораздо медленней компилируемых. Вот примерные результаты сравнения разных языков, полученные мной при работе над этой главой и главой 26 (табл. 25-1):

Табл. 25-1. Относительное быстродействие кода,

Как видите, в плане быстродействия языки С++, Visual Basic и С* примерно одинаковы. Код на Java выполняется несколько медленнее. РНР и Python - интерпретируемые языки, и код, написанный на них, обычно выполняется в 100 и более раз медленнее, чем написанный на С++, Visual Basic, С* или Java. Однако к общим результатам, указанным в этой таблице, следует относиться с осторожностью. Относительная эффективность С++, Visual Basic, С*, Java и других языков во многом зависит от конкретного кода (читая главу 26, вы сами в этом убедитесь).