Журнал LinuxFormat - перейти на главную

LXF121:Профилирование

Материал из Linuxformat
Версия от 09:43, 20 июля 2010; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

Оценка быстродействия и профилирование

Бывает, что код до ужаса тормозит. Джульетта Кемп покажет, зачем использовать черную магию тестирования производительности.

Работаете ли вы с оборудованием или с программным продуктом, на каком- то этапе скорость обязательно станет проблемой. Задача это обширная, и мы ограничимся ситуацией, когда медленно работает код, и рассмотрим, как его ускорить. Меры могут быть разными, от переписывания программы до покупки нового компьютера, но прежде всего необходимо найти основную причину и узкое место. Тут-то и пригодится тестирование производительности — и весьма важно сделать его правильно, прежде чем переходить к реформам. При сравнении различных участков кода этот процесс также иногда называют профилированием.

Тестирование производительности важно рассматривать как часть процесса усовершенствования кода. Для начала создайте код и убедитесь, что он правильно работает – а уж потом оценивайте, достаточно ли он быстр. В конце концов, нет особого смысла ускорять код, если он и так справляется: вашу энергию можно употребить на другие дела.

Повторяющийся процесс

А вот если ваш код тормозит, пора заняться тестированием. Затем используйте результаты (вместе с анализом и профилированием) для определения наилучшей точки приложения усилий. Реализовав исправления, тестируйте снова, чтобы увидеть, достаточно ли принятых мер. Если нет, переходите к следующей области и продолжайте работу.

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

Начальная оценка

Первым делом протестируйте код в его текущем состоянии. Практически всегда желательно запустить программу несколько раз подряд, чтобы выборка был репрезентативной. Это позволит усреднить длительность прогона, которая может меняться в зависимости от нагрузки процессора. Лучше всего применить скрипт-обертку, вроде такого: 

 #!/usr/bin/perl -w
 use strict;
 use Benchmark qw (:timethis);
 my $count = 10;
 timethis($count, sub {`/путь/к/программе`});

Он написан на Perl, но поскольку для вызова тестируемого кода используются обратные апострофы (`), его можно использовать для хронометража программы на любом языке, запускаемой из командной строки. В тексте скрипта вы заметите $count – это количество итераций. Другой формат – знак минус и минимальное число секунд времени процессора на прогон: например, ввод -5 приведет к запуску как минимум на 5 секунд процессорного времени.

Benchmark.pm, использованный выше модуль Perl, удобен также и для тестирования производительности программ не на Perl: просто применяйте апострофы для вызова кода из Perl-скрипта, как было сделано выше. Benchmark.pm обычно поставляется с достаточно свежей версией Perl, но может быть установлен и через CPAN. Подправив код, снова воспользуйтесь Benchmark.pm, чтобы выяснить, намного ли код стал быстрее: 

 #!/usr/bin/perl -w
 use strict;
 use Benchmark qw (:all);
 cmpthese( 10, {
               a => sub {`/путь/к/старомукоду`},
               a => sub {`/путь/к/новомукоду`},
 })

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

use Benchmark qw (:hireswallclock);

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


Ведем записи

Обертки выводят все полученные значения времени на консоль, но вывод можно перенаправить в файл (используйте wrapPer.pl >> benchmark.txt, чтобы результаты каждого прогона добавлялись к нему, не перезаписывая старых), для отслеживания прогресса.

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

Итак, настал момент запуска первого набора простых тестов. Помните, что во время тестирования не следует запускать другие задачи, иначе результаты собьют вас с толку. По возможности следует также выполнить скрипт-обертку, сам дающий усредненные результаты, несколько раз, и усреднить еще и их, добиваясь более показательного значения. Убедитесь, что ничего не загружаете: это может сказаться на скорости обработки или ввода/вывода. Желательно выполнить столько прогонов, на сколько у вас хватит времени или терпения: чем больше прогонов, тем точнее будет результат.

Профилирование: расчленяем код

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

  • раздел работы с диском (например, чтение или запись);
  • создание и/или заполнение структур данных;
  • алгоритмы и вычисления;
  • какая-либо работа с сетью (но, вероятно, здесь ускорение будет вне вашего контроля).

На данном этапе для компилируемых языков следует, веро- ятно, слегка переделать ваш код или разбить его на части. Вывод на диск убрать довольно просто – для этого иногда достаточно пару раз что-то закомментировать; но ввод с диска выкинуть сложнее, поскольку для получения результата алгоритму нужны данные. Вместо этого можно поступить наоборот, убрав все, кроме чтения; вычтите среднее время таких прогонов из среднего времени работы полной версии, и получите среднее время работы алгоритма.

Для примера допустим, что имеется три основных раздела кода: чтение данных, проведение вычислений и запись новых данных. Создайте три версии вашего кода:

A: Полная версия
B: Только чтение данных (без расчетов и вывода).
C: Чтение данных и вычисления (без вывода).

Пусть тестирование трех этих версий дало следующее: версия А выполняется 4 секунды, B – 1 секунду и C – 3,5 секунды. То есть чтение данных занимает 1 секунду (из B). Вывод данных занимает 0,5 секунды (разность между А и С). И, следовательно, вычисления идут 2,5 секунды. Вы можете найти это по формуле A – B – вывод данных = время работы (в нашем случае 4 – 1 – 0,5 = 2,5). Вот время, требуемое для работы без ввода и вывода данных.

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

Альтернатива – выводить в контрольных точках системное время. Скрипт Perl, приведенный ниже, cгенерирует при запуске по одной строке на прогон кода: 

 #!/usr/bin/perl -w
 use strict;
 use Time::HiRes;
 sub time_print;
 print time_print . “:”;
 # здесь код
 print time_print . “:”;
 # еще код
 print time_print . “\n”;
 
 sub printtime {
   my ($t1,$t2) = Time::HiRes::gettimeofday;
   my $time = “$t1.” . sprintf(“%05d”,$t2/10);
   return “$time”;

и выдаст нечто подобное: 

1240905933.05204:1240905934.05249:1240905935.05264:1240905936.05312

Значения в этих парах разделяются точками, а пары отделены двоеточием. Значения в паре – в секундах, прошедших с начала эпохи, и в микросекундах; первое – время запуска скрипта, а второе – время завершения. Использование модуля Time::HiRes позволяет выполнять подсчет в микросекундах, а не в целых секундах.

Вычисление времени

Альтернативой для хронометража при использовании Perl и Benchmark является вычисление разности времен при помощи 

 my $t1 = new Benchmark;
 # code
 my $t2 = new Benchmark;
 my $td = timediff($t1, $t2);
 print “Первый раздел потребовал $td \n”;

Однако такой результат труднее обрабатывать автоматически.

Обработка данных

Выполните код несколько раз, перенаправляя вывод в файл, а затем воспользуйтесь следующим скриптом Perl для его обработки: 


 #!/usr/bin/perl -w
 use strict;
 
 my $datafile = “testout.txt”;
 my @timearray;
 my $count = 0;
 
 open DATA, $datafile;
 while (<DATA>){
   my @time = split /:/;
   push @{ $timearray[$count] }, @time;
   $count++;
 }
 close DATA;
 
 my @result;
 for my $rowref ( @timearray ) {
   my @row = @$rowref;
   for my $i ( 0 .. ($#row – 1) ) {
   $result[$i] += $row[$i+1] – $row[$i];
  }
 }
 
 for my $i ( 0 .. $#result ) {
 print “Section “ . ($i+1) . “ average = “ . $result[$i] / $count . “\n”;
 }

Это приведет к выводу результата (как показано на экранном снимке), но учтите, что скрипт-тест выполнялся три раза, а этого мало для правильного профилирования.

Теперь вы должны иметь представление о длительности выполнения вашего кода в целом, а также его отдельных частей. Следующий шаг – ускорение.

Решение проблем

Как указывалось выше, важно найти в вашем коде узкое место, чтобы сосредоточить усилия там, где от этого будет больше всего пользы. Не исключено, что вы распознаете проблемный кусок кода, просто поглядев на цифры; а если не получится, постройте графики с помощью OOo, KChart, Guppi или Graphviz. Кто предпочитает работать в консоли, может взять gnuplot.

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

  • Обеспечьте работу локально, а не в сети. Завершив работу с файлами, перекинуть их на удаленные диски вы всегда успеете.
  • Приобретите новую периферию. Возможно, ваша старая просто уже не на высоте. Вы можете бросить ее на те участки, где скорость менее важна.
  • Выполняйте операции ввода/вывода пакетно. Например, считайте данные все разом, а затем уже обрабатывайте их в памяти. Если код выполняется несколько раз, то создайте процедуру чтения данных один раз в самом начале.
  • Понизьте «уступчивость» (nice-значение) своего процесса.

Для просмотра текущих параметров диска можно применить hdparm (например, hdparm -v /dev/hda). Можно увеличить скорость работы накопителя лобовой атакой – включить прямой доступ к памяти (Direct Memory Access, DMA) (hdparm -d1 /dev/hda); затем вновь оцените быстродействие и посмотрите, сработало ли это. Также можно изменить значение поддержки ввода/вывода (I/O support) опцией -c3, это также способно слегка улучшить быстродействие. Поэкспериментируйте с другими значениями hdparm, но будьте осторожны: некоторые из них могут быть опасны. Перед выполнением действий почитайте man-страницу. При желании сохранить произведенные изменения, выполните hdparm -k /dev/hda.


Подгонка файловой системы

Вы можете ускорить доступ к файлам, отключив ведение временных отметок при каждом обращении к ним – то есть не делая запись в каталог при каждом открытии файла. Для этого отредактируйте /etc/fstab, добавив noatime к списку опций в четвертом столбце для каждой ФС, которую вы хотите изменить, а потом все перемонтируйте командой mount -a. Однако отсутствие записей о доступе к файлу способно вызвать проблемы в некоторых программах: почтовых или резервного копирования. Хотя можно создать для своего приложения отдельный раздел и использовать noatime только в нем.

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

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

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

Параллельная обработка

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

Strace и ltrace

Strace выводит список системных вызовов, выполненных программой. Обычно для тестирования это перебор, но тут есть пара полезных опций. Например, -c записывает время каждого системного вызова, -r выводит относительное время каждого системного вызова, а -t – абсолютное (для включения микросекунд используйте -tt). -T выводит время, потраченное на системный вызов. С опцией -e будут отслеживаться только определенные наборы системных вызовов.

ltrace выполняет то же самое, но для библиотечных вызовов. И вновь -c посчитает время вызовов и возвратит сводку, а -t и -tt покажут время суток при запуске каждой строки.

Заключение

Для получения более подробной информации о том, где тормозит ваш Perl-код, можно запустить Devel::NYTProf или его предшественника Devel::DProf – это всеобъемлющие профилировщики с хорошей документацией. Используя данные инструменты, вы сможете найти проблемные места конкретных модулей и обдумать пути их исправления. Не забудьте потом опять выполнить профилирование, чтобы проверить, есть ли сдвиг.

Если вы используете Perl или другой скриптовый язык, и способов ускорения кода не обнаруживается, а быстродействие совершено неприемлемо, то, возможно, надо перейти на компилируемый язык – типа C, C++ или Java. Однако, прежде чем погрузиться в это и полностью переделать код, следует хорошенько убедиться, что это действительно стоит вашего времени и затраты усилий. Еще раз рассмотрите результаты тестирования и убедитесь, что сделали все возможное для ускорения и дальше здесь ехать некуда.

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

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

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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF121:%D0%9F%D1%80%D0%BE%D1%84%D0%B8%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5&oldid=10568»
Персональные инструменты
купить
подписаться
Яндекс.Метрика