Мільйон і один день INotifyPropertyChanged

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

image
Користувальницький інтерфейс повинен бути швидким, дуже швидким, неймовірно швидким.
У спробах заощадити наносекунди за часту упускаються місця де можна економити секунди. Забавно, одного разу на моє обурення про двох секундної від хизування невеликого списку, я отримав відповідь «Дабпиэф нічого не поробиш», серйозно? Вивчаючи різноманітні варіанти реалізації INotifyPropertyChanged habrahabr.ru/post/281294 виникає питання про ідеальному балансі продуктивності інтерфейсу користувача і розробника, який займається цим інтерфейсом. Захотілося зрозуміти як вплине на роботу інтерфейсу вибір конкретної реалізації.

Наші атлети:

  1. imageOnPropertyChanged(string) — класичний виклик з передачею імені властивості
  2. imageOnPropertyChanged(nameof) — те ж що і попередній, але...
  3. imageOnPropertyChanged([CallerMemberName]) — автоматичного визначення імені властивості
  4. imageOnPropertyChanged(()=>Expression) — передача виразу зі властивістю
  5. imageSetProperty<T>(ref T storage, T value, [CallerMemberName]) — гібрид
  6. imageObservableObject<T> — про це нам повідав astudent
  7. imageАОП — проксі згенерований Unity, реалізація минулого топіка


(Розмальовка равликів — найцікавіше, згубний вплив догляду під frontend)
Біг буде відбуватися в мішках, для цього кожен з учасників буде підписаний на PropertyChanged (порожній статичний метод), а так само буде реалізувати загальний інтерфейс, на цьому етапі особлива увага приділяється учаснику №6, в силу його вроджених мутацій. Якщо інтерфейс ще можна вкарячить, то підписуватися доведеться через DependencyPropertyDescriptor, він вирішив випендритися. Траса — цикл в 10 мільйонів, для кожного учасника.

На старт! Увага! Го!

Справа не швидке, доведеться почекати.


image
Експеримент проводився декілька разів і результати приблизно не відрізняються.
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. економія наносекунд в подібних випадках марна, як правило більшість проблем з продуктивністю лежать не тільки в технології, але і досить велика частка в їх кривому використанні.

Наступне без слів...image


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

0 коментарів

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