Порівняння продуктивності UI в WPF, Qt, WinForms і FLTK

Під мірою продуктивності UI, будемо розуміти кількість відгуків на дії користувача в одиницю часу. А під відгуком — запитувану користувачем реакцію програми.

Малим часом відгуку, можна пояснити ряд переваг користувача:
1. Перевага аналогових інтерфейсів цифрових (когада виникає затримка на обробці цифрового введення)
2. На зорі Windows, — уподобання користувачів працювати з DOS програмами в «текстовому режимі», а не з GUI аналогами в Windows (час відгуку в текстовому режимі тоді було помітно менше на подібною платформі)
3. Перевагу реальних ігрових консолей їх эмуляторам (емулятори часто мають час відгуку відрізняється від часу відгуку оригінальних консолей)
4. Перевагу користувачів iOS і Android щодо WinCE і Symbian (серед іншого, наприклад в iOS ставилася мета швидкого відгуку і підтримки 60 FPS, Android хоча і не ставив таких цілей було помітно чутливішими WinCE і Symbian)
5. В автомобілях — неоднозначне ставлення користувачів до автоматичною коробками передач, електронної педалі газу і деяким іншим системам вносять затримку між керуючим впливом і реакцією на нього (це відноситься до найменш " просунутим версіями цих рішень)

Великий час відгуку є по суті «зворотним зв'язком з запізненням», про яку більш докладно можна прочитати тут: «Зворотній зв'язок з запізненням в крані з гарячою водою, марсохід та демографічної піраміді»


Порівняння продуктивності
Затримка реакції на введення користувача в цифрових системах природна і неминуча. Однак у UI для сприйняття значення мають тільки ті затримки, які користувач в змозі відчути. Наприклад, у сприйнятті візуальної інформації середньостатистичний користувач не здатний розрізнити затримки менш 1/60 секунди, тому подальше зменшення часу візуального відгуку навряд-чи буде виправдано.

Розглянемо чуйність користувальницького інтерфейсу бібліотек WPF Qt WinForms , FLTK. Важко виміряти чуйність всіх контролів цих бібліотек, і складно в кожному випадку виміряти інтервал між введенням користувача і реакцією контрола на цей enter. Тому, трохи спростимо задачу оцінки. Будемо тестувати один, але складний, і в цілому показовий контрол, присутній у всіх бібліотеках — DataGrid. Чуйність будемо мірятиFPS у відгуку на скролінг вмісту цього контрола. Для того щоб уникнути підрахунку неповних кадрів, будемо використовувати подвійну буферизацію.

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

Для кожної бібліотеки я підготував по тестового додатком, заповнюють грід даними однакового виду. Ці дані — 5000 рядків по 20 колонок з якоюсь довільною інформацією (вважаю таку кількість рядків і стовпців близьким до реальних максимальним потребам відображення складних об'єктів). Я не оптимізував заповнення гріду, тому не варто надавати значення тому, що для деяких бібліотек він заповнюється повільно. Продуктивність будемо міряти вже після того як грід заповнений.

Продуктивність я перевіряв тільки під Windows (хоча бібліотеки, за винятком WPF кросплатформенны), для перевірки був написаний лічильник FPS (тільки для Windows 32-бітної глибини кольору) визначає зміни кадру по верхній частині основного екрана. Похибка лічильника може бути близько 1 кадру.

Методика вимірювання продуктивності:
1. Запускаємо лічильник FPSCounter.exe.
2. Запускаємо одне з тестових додатків FltkGrid.exe, FormsGrid.exe, QtGrid.exe або WpfDatagridTest.exe і розгортаємо його на весь основний екран (це необхідно т. к. детектується тільки зміна верхній частині кадру на основному екрані)
3. Рухаємо бігунок вертикального скроллера гріду вгору і вниз до упору, під час руху бігунка дивимося значення FPS в верхньому лівому куті екрану або у вікні лічильника. (для отримання максимальних значень FPS рухати повзунок треба швидко, інакше ми зіткнемося у власну «продуктивність», а не продуктивність UI)

Вимірювання FPS я виробляв на декількох, які опинилися під рукою платформах, майже всі платформи на Windows 7 x64, інші додатки на час вимірювань закривав.

Архів з FPSCounter.exe, FltkGrid.exe, FormsGrid.exe, QtGrid.exe і WpfDatagridTest.exe, а так само Qt бібліотеками, необхідними для тестової програми на Qt (16 Mb)

Архів з FPSCounter.exe, FltkGrid.exe, FormsGrid.exe ( тобто без Qt, зате дуже маленький)

Додатки скомпільовані під х64 платформу. Крім цього для запуску може знадобитися msvs runtime 2010

Результати
Нижче наведена таблиця з переліком платформ, на яких запускалися вимірювання та їх результатами. У таблиці також вказано оцінка однопоточній продуктивності платформи (Single Thread Performance) відповідно до www.cpubenchmark.net



В доповнення до таблиці, хочу додати, що додатки Office і наприклад браузер Chrome (на «хороших» сторінках) показують FPS приблизно рівний FLTK або трохи менше.

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



Графік варто трохи прокоментувати. На платформі з оцінкою 1000 використовувалося низька вертикальна роздільна здатність екрана що сильно зменшило число видимих осередків, тим самим істотно підвищивши FPS вертикального скроллирования. Хочу також додати, що для компіляції FLTK прикладів був відключений ряд оптимізацій, тому цілком можливо включивши їх, можна дещо збільшити оцінки прикладу FLTK на всіх платформах (з цієї ж причини під час старту прикладу FLTK з'являється вікно консолі)
В цілому ж, залежність FPS від однопоточній продуктивності процесора досить лінійна. Є припущення що багатопотокова продуктивність поки мало застосовна до UI бібліотек (наприклад, перевагу i7 в многопоточной продуктивності мало впливає на FPS). Так само вимірювання показали слабку залежність FPS в нашому тесті від відеокарти (залежність безумовно є, але схоже у даних тестах відеокарта не є вузьким місцем) Ще однією цікавою деталлю стало обмеження 30 FPS на ряді платформ. Не впевнений чи пов'язано це c драйвер відеокарти або якимись її налаштуваннями, проте в ряді випадків не вдавалося отримати більше 30 FPS…

Виключно на підставі даних вимірювань я не можу рекомендувати FLTK, як універсальний засіб підвищення чутливості вашого UI, тим більше що писати UI на FLTK вельми трудомістко (на написання FLTK прикладу у мене пішло близько 20ти хвилин, хоча інші приклади були написані помітно швидше). Однак результати вимірювань змушують замислитися про те, що за багато бібліотек не повністю розкривають потенціал заліза на якому виконуються, роблячи додатки менш привабливими для користувача(з точки зору чуйності принаймні).

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

Додаю вихідні коди лічильника і тестів.

Як же отримати високий FPS?
Як видно з тіста, стабільні 60 FPS, у разі важкого UI ми отримаємо хіба що на дорогому залозі і найбільш витратною в розробці UI бібліотеці (тобто дорогим буде і розробка та залізо і споживання цього заліза) напевно іноді це того варто, але поки це швидше виняток. Однак, якщо не вдаватися в крайнощі і поставити собі за мету отримати хоча б 20 FPS в навантажених інформацією інтерфейсах. Чого нам це буде коштувати?

Для розглянутих бібліотек, варіантів, мабуть, не так і багато:
1. FLTK + майже найдешевше залізо. На розробку UI ми витратимо помітно більше часу, але в поточних цінах зможемо заощадити ~100-200$ на залозі на робоче місце користувача.
2. Qt + середнє залізо. На залозі заощадити особливо не вийде, але зате розробка UI буде дешевше ніж у випадку FLTK. Ймовірно в ряді випадків варіант буде оптимальним.
3. WPF + дороге залізо тобто додаткові 200-300$ на робоче місце. Адже якщо на i7-3770 ми отримуємо тільки 12 кадрів, то потрібно як мінімум залізо в півтора рази потужніший. Ймовірно i7-5930K чи можливо i7-4790K в парі з хорошою відеокартою впораються із завданням 20 FPS. Однак навряд чи це буде ефективне рішення, так і впораються… на жаль немає такого заліза під рукою щоб перевірити, але якщо екстраполювати однопоточную продуктивність те її оцінка повинна бути понад 3000, для отримання 20 FPS при 1280х1024… такого заліза просто не існує, принаймні тут
4. Полегшувати UI, до тих пір поки не вкладемося в 20 FPS. Наприклад, якщо використовуючи WPF, замість 20ти колонок в гріді залишити лише 6, то на i7-3770 ми отримаємо стабільні 20 FPS, якщо ж залишити всього 3-4 колонки, то отримаємо 20 FPS і на бюджетному залозі. Зменшення розміру самого гріду також має дати позитивний ефект (правда на різних бібліотеках він різний, і як не дивно для випадку WPF ефект найменш виражений). Прийнятні такі рішення? Застосовні далеко не скрізь, але все-таки покривають ряд завдань, не фокусирующихся на представленні даних.

P. S.: Ідея порівняти продуктивність гридов з'явилася після того, як я зіткнувся з низькою продуктивністю гріду WPF. У коментарях до моєї попередньої статті Вибір між C++ і C# я, зокрема, розбирав цю проблему.
Далі мені стало цікаво, як з завданням відображення гріду справляються альтернативні бібліотеки, так з'явилися тестові програми та результати викладені в цій статті.

Який мінімальний FPS ви вважаєте комфортним для роботи з додатком

/>
/>


<input type=«radio» id=«vv68211»
class=«radio js-field-data»
name=«variant[]»
value=«68211» />
3-6
<input type=«radio» id=«vv68213»
class=«radio js-field-data»
name=«variant[]»
value=«68213» />
8-12
<input type=«radio» id=«vv68215»
class=«radio js-field-data»
name=«variant[]»
value=«68215» />
15-20
<input type=«radio» id=«vv68217»
class=«radio js-field-data»
name=«variant[]»
value=«68217» />
20-30
<input type=«radio» id=«vv68219»
class=«radio js-field-data»
name=«variant[]»
value=«68219» />
30-60
<input type=«radio» id=«vv68221»
class=«radio js-field-data»
name=«variant[]»
value=«68221» />
рівно 60
<input type=«radio» id=«vv68223»
class=«radio js-field-data»
name=«variant[]»
value=«68223» />
60

Проголосувало 143 людини. Утрималося 60 чоловік.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.