Оптимізації інтерфейсу користувача присвячується.
Інтерфейс користувача повинен бути швидким, дуже швидким, неймовірно швидким.
У спробах заощадити наносекунди часто втрачаються місця де можна економити секунди. Забавно, однажды на мое возмущение о двух секундной отрисовке небольшого списка, я получил ответ «Дабпиеф ничего не поделаешь», серьезно? Вивчаючи всілякі варіанти реалізації INotifyPropertyChanged habrahabr.ru/post/281294 виникає питання про ідеальний баланс продуктивності користувацького інтерфейсу і розробника, який займається цим інтерфейсом. Захотілося зрозуміти як вплине на роботу інтерфейсу вибір конкретної реалізації.
Наші атлети:
- OnPropertyChanged (string) - класичний виклик з передачею назви властивості
- OnPropertyChanged (nameof) - те ж що і попередній, але...
- OnPropertyChanged ([CallerMemberName]) - автоматичне визначення назви властивості
- OnPropertyChanged ((() = > Expression) - передача виразу з властивістю
- SetProperty<T>(ref T storage, T value, [CallerMemberName]) — гибрид
- ObservableObject & ltT & gt - про це нам повідав astudent
- АОП - проксі згенерований Unity, реалізація з минулого топіку
(Розмальовка равликів - найцікавіше, згубний вплив відходу у frontend)
Біг буде відбуватися в мішках, для цього кожен з учасників буде підписаний на PropertyChanged (порожній статичний метод), а так само буде реалізувати загальний інтерфейс, на цьому етапі особлива увага приділяється учаснику № 6, в силу його вроджених мутацій. Якщо інтерфейс ще можна вкарячити, то підписуватися доведеться через DependencyPropertyDescriptor, він вирішив випендритися. Траса - цикл у 10 мільйонів, для кожного учасника.
На старт! Увага! Го!
Справа то не швидка, доведеться почекати.
…
…
Експеримент проводився кілька разів і результати приблизно не відрізняються.
|
10 000 000 |
1. string |
2. nameof |
3. CallerMemberName |
4. Expression |
5. SetProperty |
6. ObservableObject |
7. AOP |
Seconds |
0,129 |
0,13 |
0,121 |
9,016 |
0,372 |
4,248 |
22,643 |
Нагородження.
Перше місце заслужено отримують равлики 1,2,3!
Другий равлик № 5, не багато не дотягнув
Бронза заслужено дістається нестандартному рішенню № 6
Далі йдуть вирази
І замикає все це справа равликовий майстер спорту, його згубила рефлексія.
Підбиття підсумків.
Очевидно, що для досягнення максимальної швидкості потрібно брати інструменти з сімейства 1,2,3. Використання аоп гальмує додаток геть, ну звичайно використовувалося неоптимальне рішення, можна оптимізувати рефлект надавши делегатів, з економивши секунди 3, але загальної картини це не змінить.
А тепер по факту! Використання будь-якої з реалізацій ніяк не впливає на продуктивність. 10 мільйонів викликів займають 25 секунд, це означає для зависона на секунду потрібно зробити 400к викликів! 400к, якщо раптом таке трапитися VM потрібно розчинити в кислоті, без горя і жалю.
P.S. економія наносекунд в подібних випадках марна, як правило більшість проблем з продуктивністю лежать не тільки в технологіях, але і досить велика частка в їх кривому використанні.