Профіліровщік Quantify

Введення

Quantify, вставляючи налагоджувальний код в бінарний текст тестового модуля, заміряє тимчасові інтервали, які пройшли між попереднім і поточними запусками. Отримана інформація відображається у кількох видах: табличному, графічному, комбінованому.

Статистична інформація від Quantify дозволить дізнатися які dll бібліотеки брали участь у роботу додатку, дізнатися список всіх викликаних функцій з їх іменами, формальними параметрами виклику й з статистичними аналізатором, що показує скільки кожна функція виконувалася.

Гнучка система фільтрів Quantify дозволяє, не захаращуючи екран зайвими висновками (наприклад, системними викликами) дозволяє отримувати необхідну інформацію або тільки про внутрішні, програмних виклики або тільки про зовнішні, або комбінуючи обидва підходи.

Озброївшись отриманої статистикою, розробник без праці виявить вузькі місця в продуктивності тестової програми та усуне їх в найкоротші терміни.

Запуск додатків

Малюнок 1 показує дії після вибору «File-> Run», в результаті якого можна вибрати ім'я зовнішнього модуля і аргументи його дзвінка.

В Як параметри налаштування можна вибрати метод вставки налагоджувальному коду:

Line. Найкращий спосіб вставки налагоджувальному коду. Заміряється час виконання кожного рядка тестуємого додатки.

Function. Те ж саме, що і для «line», але з виміром для виконавчі викликаються функцій.

Time. Здійснює збір тимчасової інформації і на основі цього ви машинні цикли.

За замовчуванням Quantify збирає статистичну інформацію в модулі тестуємого продукту і у всіх зовнішніх бібліотеках.

Початок насичення тестової програми супроводжується появою вікна інструментірованія, в якому порядково відображаються всі модулі, що викликаються основним. Дані модулі, як говорилося вище, насичуються налагоджувальний кодом і поміщаються в спеціальну директорію «cache» за адресою «Rationalquantifycache». Відзначимо, що початковий запуск інструментірванія процес тривалий, але кожний наступний виклик скорочує загальний час очікування в силу того, що вся необхідна інформація вже є в Кеші.

З точки зору дискової ємності, файл (Кешована) налагоджування від Quantify вдвічі довший за свого побратима без налагоджувальної інформації.

Аналіз інформації

«Run Summary»

Плавно переходимо до наступної стадії тестування, власне, до збору інформації. За закінчення процесу насичення налагоджувальний кодом модулів тестової програми, Quantify переходить до його виконання, вироблених, звичайним чином, за одним винятком: запис станів тестової програми продовжує проводитися в фоновому режимі.

Малюнок 3 демонструє фрагмент вікна «Summary», в якому проводиться запис стану тестової програми. Причому, що дуже примітно, тестування проводиться не тільки для простого додатка, але і для багато поточного. В останньому випадку (див. малюнок 3), тестується кожен потік окремо. У будь-якому випадку, навіть якщо додаток Однопотокові, то ім'я основного (єдиного) потоку іменується як «. main_0», що видається цілком логічним.

Інформаційний графік поступово наповнюється квадратами різного кольору, що демонструють поточний стан тестової програми.

Відзначимо із деякі них:

Running. Початок виконання потоку;

Waiting IO. Очікування дій з вводувиводу;

Blocked. Блокування виконання потоку;

Quantify. Очікування виклику модуля Quantify;

Exited. Закінчення виконання потоку.

Важливий аспект при тестуванні - отримання статистичної інформації про кількість зовнішніх бібліотек, що викликало основну програму, а також елементарне опис машини, на якій проводилося тестування. Останнє особливо важливо, так як буває, що помилка проявляється тільки на процесорах строго певної серії або виробника. Всі статистичні аспекти вирішуються всередині вікна «Summary».

Наступні два приклади показують статистичну інформацію:

(1) Загальний звіт - «Details»:

Program Name: C: projectsaaDebugaa.exe

Program Arguments:

Working Directory: C: projectsaaDebug

User Name: Alex

Product Version: 2002.05.00 4113

Host Name: ALEX-GOLDER

Machine Type: Intel Pentium Pro Model 8 Stepping 10

# Processors: 1

Clock Rate: 847 MHz

O/S Version: Windows NT 5.1.2600

Physical Memory: 382 MBytes

PID: 0xfbc

Start Time: 24.04.2002 14:17:38

Stop Time: 24.04.2002 14:17:52

Elapsed Time: 13330 ms

# Measured Cycles: 191748 (0 ms)

# Timed Cycles: 2489329 (2 ms)

Dataset Size (bytes): 0x4a0001.

(2) «Log»

Quantify for Windows,

Version 2002.05.00; Build: 4113;

WinNT 5.1 2600 Uniprocessor Free

Instrumenting:

Far.exe 620032 bytes

ADVAPI32.DLL 549888 bytes

USER32.DLL 561152 bytes

SHELL32.DLL 8322560 bytes

WINSPOOL.DRV 131584 bytes

MPR.DLL 55808 bytes

RPCRT4.DLL 463872 bytes

GDI32.DLL 250880 bytes

MSVCRT.DLL 322560 bytes

SHLWAPI.DLL 397824 bytes

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

Дерево викликів «Call Graph »

Наступний найцікавіший спосіб аналізу конструкції додатки - це перегляд дерева викликів. Вікно, показане на 4 малюнку, показує лише фрагмент вікна з діаграмою дзвінків.

Зверніть увагу на кількість і послідовність виклику різних модулів потоку «Main». Жирна лінія показує найбільш тривалі гілки (що містять або часто викликаються функції, або функції, що виконувалися довше інших). Для демонстрації можливостей Quantify було сконструйовано простий додаток, що складається з функції "main» і двох додаткових «recursive» і «outside» (див. лістинг 1).

Лістинг 1. Приклад тестового додатки, сконструйованому у вигляді консольного застосування з Visual Studio 6.0. Мова реалізації «С».

# include "stdafx.h"

// Створюємо функцію-заглушку

void outside (void)

(

static int v = 0;

v ++;

)

// Створюємо рекурсивну функцію, реклама, яка 100 раз

int recursive (void)

(

static int i = 0;

int oo;

outside ();// Викликаємо функцію заглушку

if (i == 100) (i = 1; return 0;)// Обнуляємо лічильник і виходимо

i ++;

recursive ();

)

int main (int argc, char * argv [])

(

int i;

for (i = 0; i <100; i + +) recursive ();

// Викликаємо 100 раз рекурсивну функцію 100х100

return 0;

)

Додаток просте по суті, але дуже змістовне, так як ефективно демонструє основні можливості Quantify.

В самому початку статті ми висували вимогу, за яким розробникам не рекомендується користуватися рекурсивними функціями.

Тестери або розробники, побачивши діаграму викликів, виділять функцію, що знаходиться в півколі, що є ознакою рекурсивного виклику (див. малюнок).

В залежно від того, на якій з гілок дерева, знаходиться курсор, виводиться додаткова статистична інформація про тимчасовий доступ до виділеної функції і до дочірніх, що йде нижче.

Наступний малюнок демонструє статистику по функції «recursive».

Більше докладно про статистику буде розказано в наступному матеріалі.

Список викликів функцій «Function List»

Одне з найбільш важливих статистичних вікон. Тут у табличному вигляді виводиться статистична інформація по числу і часу роботи кожної функції. Малюнок 6 демонструє вікно з включеною сортуванням за кількістю викликів кожної функції. У як додаткова інформація включений список формальних параметрів викликів функцій. Подібну інформацію можна отримати тільки в тому випадку, коли тестується модуль налагоджування кодом, до якого додається вихідний текст.

Одиниці виміру тривалості роботи функцій можуть бути наступними:

мікросекунди;

мілісекунд;

Секунди;

Машинні цикли.

На малюнку наведені цифри відповідні машинним циклами.

Отримана таблиця викликів аналізується тестером або розробником для з'ясування вузьких місць в продуктивності програми.

До жаль, для ухвалення рішення про продуктивність програми, а точніше, продуктивності окремих його функцій можна приймати тільки розглядаючи дане питання в комплексному розрізі. А саме, береться до уваги і число викликів кожної функції, і середній час доступу до функції і загальний час роботи функції, і, нарешті, те використовувалися чи при компіляції певні специфічні настройки компілятора.

Це комплексний підхід, що не припускає однозначного ради.

Спочатку розглянемо опис стовпців в таблиці, що з'явилася. Хоча багато хто з пунктів і є інтуїтивно зрозумілими, все ж спробуємо дати їм короткий опис:

Function. Найменування функції. Можна висвічувати число і тип формальних параметрів виклику даної функції.

Calls. Число викликів. Величина абсолютна.

Function Time. Загальний час виконання всіх викликів даної функції

Max F Time. Максимальний час функції

Module. Повний шлях до модуля з функцією (бінарного)

Min F Time. Мінімальний час роботи функції

Source File. Повний шлях до вихідних текстів модуля.

За будь-якого із запропонованих полів можна провести сортування в прямому і зворотному порядку, а також накласти фільтр на певні модулі, наприклад, для перевірки тільки внутрішніх модулів або тільки зовнішніх.

Виділити зі списку вузьку функцію важко, оскільки для правильного розрахунку потрібно брати до уваги і час роботи функції і число викликів. Причому, число викликів не завжди може бути показником повільності функції (викликається часто, а працює швидко).

Важко давати будь-які поради з оптимізації коду, тим більше, що в цій редакції ми не ставили перед собою подібних цілей. За теорією оптимізації написані величезні праці, до яких ми з радістю і відправляємо читачів.

Можна, звичайно, дати загальні рекомендації щодо поліпшення продуктивності коду і його ефективності:

Використовувати конструкцію «I + +» замість «I = I +1», так як компілятори транслюють першу конструкцію в більш ефективний код. На жаль, цей ефективність прикладу обмежена налаштуваннями використовуваного компілятора, і іноді буває рівнозначної за швидкодією;

Використовувати прийом розгортання циклів. Такий самий старий прийом оптимізації роботи відносно простих циклів. Ефект полягає в скороченні кількості перевірок умови лічильника, так при перевірці виконуються дуже повільні функції мікропроцесора (функції переходу). Тобто замість коду:

For (i = 0; i <100; i + +) sr = sr 1;

Краще писати:

For (i = 0; i <100; i + = 2)

(

sr ++;

)

Використовувати тактику відмови від Використання обчислюваного конструкцій всередині простих циклів. Тобто, якщо мати подібний фрагмент коду:

for (sr = 0; sr <1000; sr ++)

(

a [sr] = X * y;

)

то його краще перетворити в такий:

mn = x * y;

for (sr = 0; sr <1000; sr ++)

(

a [sr] = Mn;

)

оскільки ми "забрали від зайвої операції множення в простому циклі;

Там де можливо при роботі з багатовимірними масивами, поводитися з ними як з одновимірними. Тобто, якщо є необхідність у копіювання або ініціалізації, наприклад, двовимірного масиву, то замість коду:

int sr [400] [400];

int j, i;

for (i = 0; i <400; i ++)

for (j = 0; j <400; j ++)

sr [j] [i] = 0;

краще використовувати конструкцію, в якій немає вкладеного циклу:

int sr [400] [400];

int * p = & sr [0] [0];

for (int i = 0; i <400 * 400; i ++)

p [sr] = 0;// або * p + + = 0, що для більшості компіляторів одне й теж

Також при роботі з циклами вигідно використовувати злиття, коли кілька коротких однотипних циклів зливаються разом. Подібний підхід також дає приріст у продуктивності коду;

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

Короткі функції у класах краще оформляти вбудованими (inline);

В строкових операціях, в операціях копіювання масивів краще користуватися не власними функціями, а застосовувати для цього стандартні бібліотеки компілятора, тому що ці функції, як правило, вже оптимізовані по швидкодією;

Використовувати команди SSL і MMX, оскільки в досить широке коло завдань вони здатні дати прискорення роботи додатків в рази. Під такі завдання потрапляють завдання по роботі з матрицями і векторами (арифметичні операції над матрицями та векторами);

Використовувати інструкції зсуву замість множення і ділення там, де це дозволяє робити логіка програми. Наприклад, інструкція S = S <<1 завжди ефективніше, ніж S = S * 2;

Звичайно, це далеко не повний список прийомів оптимізації коду по продуктивності і якості. Для цього є маса інших книг. Приклади тут мають чисто утилітарний підхід: демонстрація можливостей Quantify в плані дослідження тимчасових характеристик коду.

Використовуючи всі кошти збору і відображення, розробник поступово зможе використовувати тільки ефективні конструкції, що підніме продуктивність на недосяжну раніше висоту.

За будь-якої функції можна вивести більш детальний звіт (див. малюнок). З нього можна почерпнути інформацію про кількість дочірніх функцій і те, звідки вони були зроблені. Наступний малюнок демонструє цю можливість.

Перехід до перегляду початкового тексту.

Якщо тестовий модуль супроводжується вихідним текстом, то в Quantify є можливість з переходу на рівень перегляду початкового тексту. За контекстного меню можна здійснити цей перехід. Викликати функцію переходу має сенс тільки в тому випадку, коли Quantify працює в незалежному режимі, у відриві від середовища розробки. Малюнок демонструє даний режим.

Порівнювання запусків «Compare Runs»

В більшості випадків потрібно мати не тільки відомості про окремі запуски, але й порівняння різних запусків у різних комбінаціях для прогнозування та аналізу. Адже завжди цікаво знати швидко працює виправлена функція або повільно, в порівнянні з тим, що було до цього.

Подібна аналітична інформація дозволити мати досить чітке уявлення про те чи знаходяться функції в прогресуючому або в регресуючим стані.

Для виклику модуля порівняння необхідно скористатися кнопкою (Compare Runs), виділивши один з запусків, і вказавши на будь-якій іншій (кожен новий запуск відображається в історії запусків на лівій частині робочого поля Quantify).

Для здійснення не порожнього порівняння, як приклад, розглянутий вище, навмисно були внесені зміни, які збільшили число викликів функцій. Дані були збережені і переконфігурувати і знову виконані в Quantify. Результат представлений на малюнку:

Порівняння запусків дозволяє проводити порівняльний аналіз між базовим запуском (base - Те, з якого все почалося) і новим (new).

Результати порівняння також залишаються в проекті Quantify і зберігаються протягом життєвого циклу розробки проектів.

Нарівні з порівнянням запуск можна скористатися підсумовуванням, натиснувши на кнопку . Ця функція викликає просте підсумовування чисел від двох запусків.

Можна порівнювати і складати також запуски разом зі зліпками (snapshot), які дозволяють оформити поточний кількісне стан в роботі додатку у вигляді окремого запуску. Надалі над ним можна провести будь-яку логічну операцію.

Цінність зліпків проявляється тоді, коли необхідно дізнатися число викликів кожної функції до звершення певної події, наприклад, до входу в певний пункт меню в тестованому додатку.

API

Це додаткова можливість, що надається Quantify за повним управління процесомтестування. API представляє собою набір функцій, які можна викликати з тестової програми на розсуд розробника.

Для отримання доступу до API необхідно виконати низку дій з підключення «Puri.h» файлу з визначенням функцій і з включенням «pure_api.c» файлу в складу проекту. Єдине обмеження, що накладаються API - рекомендації по постановці точок зупинки після дзвінків Quantify при виконанні програми під відладчиком.

Розглянемо наявні функції API Quantify:

QuantifyAddAnnotation. Дозволяє задавати словесний опис, що супроводжує тестування коду. Інформація, визначена розробником цією функцією може бути вилучено з пункту «details» меню тестування і доступна в LOG-файлі. На її основі, тестер може згодом використовувати особливі умови тестування;

QuantifyClearData. Очищає все незбережені дані;

QuantifyDisableRecordingData. Забороняє подальшу запис;

QuantifyIsRecordingData. Повертає значення 1 або 0 в залежності від того чи здійснюється запис властивостей чи ні;

QuantifyIsRunning. Повертає значення 1 або 0 в залежності від того проходить тестованої додаток виконання в звичайному режимі або під Quantify;

QuantifySaveData. Ця функція дозволяє зберігати поточний стан - робити знімок (snapshot);

QuantifySetThreadName. Функція дозволяє розробникам іменувати потоки в довільному іменному поле. За замовчуванням Quantify дає імена, на зразок «thread_1», що може не завжди позитивно позначатися на читання одержуваної інформації;

QuantifyStartRecordingData. Починає запис властивостей. За замовчуванням, ця функція автоматично викликається Quantify при виконанні;

QuantifyStopRecordingData. Зупиняє запис властивостей.

Якщо модифіковані наше тестове програму так, щоб воно використовувало переваги інтерфейсу API, то може вийти щось наступне

int main (int argc, char * argv [])

(

int i;

QuantifyAddAnnotation ( "Тестування проводиться під Quantify з використанням API ");

QuantifySetThreadName ( "Основний потік програми ");

for (i = 0; i <12; i ++){

QuantifySaveData ();

recursive ();

)

return 0;

)

В лістингу показано як можна використовувати основні функції API для видобування максимального статистичного набору даних.

Малюнки показують зліпки фрагментів екрана Quantify після закінчення тестування.

Рис. Даний малюнок демонструє вигляд вікна після виконання команди зняття відбитку або виклику функції API QuantifySaveData ()

Рис. Зверніть увагу на поле анотації

Рис. У Quantify відсутні труднощі з російськими літерами

Збереження даних і експорт

Традиційні операції над файлами притаманні і програмі Quantify. Додаткові особливості полягають в тому, що зберігати дані можна як у вбудованому форматі (qfy), для кожного окремого запуску, так і в текстовому вигляді, для подальшого використання в текстових редакторів, або для подальшої обробки скриптовою мовами типу perl (більш докладно про це дивіться в розділах по ClearCase і ClearQuest).

Quantify дозволить переносити таблиці через буфер обміну в Microsoft Excel, що відкриває безмежні можливості по множинного порівнянні запусків, з побудови графіків і різних форм. Все, що необхідно зробити - це тільки скопіювати дані з однієї програми і помістити в іншу відомим способом.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://software-testing.ru