Million and one day INotifyPropertyChanged
User interface optimization is dedicated.
Trying to save nanoseconds often misses places where you can save seconds. It's funny, once upon my outrage about two seconds of drawing a small list, I received the answer “Dubiaf can not be helped,” seriously? Studying all sorts of options for implementing INotifyPropertyChanged habrahabr.ru/post/281294 raises the question of the perfect balance of user interface performance and the developer who deals with this interface. I wanted to understand how the choice of a specific implementation will affect the operation of the interface.
(Coloring snails - the most interesting, detrimental effect of care in the frontend)
Running will happen in bags, for this each participant will be signed on PropertyChanged (empty static method), and will also implement a common interface, at this stage special attention is paid to participant No. 6, due to his innate mutations. If the interface can still be screwed up, then you will have to subscribe through DependencyPropertyDescriptor, he decided to show off. The track is a cycle of 10 million for each participant.
')
The thing is not fast, you have to wait.
...
...
The experiment was conducted several times and the results do not differ approximately.
Snails 1,2,3 deservedly get the first place!
The second snail number 5, not much fell short
Bronze deserved goes to non-standard solution number 6
Next come the expressions.
And the snail master of sports closes the whole thing, reflection has ruined him.
Obviously, to achieve maximum speed, you need to take tools from the 1,2,3 family. Using the application will slow down the application completely, but of course a non-optimal solution was used, you can optimize the reflection by creating delegates, saving 3 seconds, but this will not change the overall picture.
And now in fact! Using any of the implementations does not affect performance. 10 million calls take 25 seconds, which means that for a second you need to make 400k calls for a second! 400k , if suddenly this happens VM need to be dissolved in acid, without grief and regrets.
PS saving nanoseconds in such cases is useless, as a rule, most performance problems lie not only in technologies, but also a fairly large share in their curved usage.
The user interface has to be fast, very fast, and incredibly fast.
Trying to save nanoseconds often misses places where you can save seconds. It's funny, once upon my outrage about two seconds of drawing a small list, I received the answer “Dubiaf can not be helped,” seriously? Studying all sorts of options for implementing INotifyPropertyChanged habrahabr.ru/post/281294 raises the question of the perfect balance of user interface performance and the developer who deals with this interface. I wanted to understand how the choice of a specific implementation will affect the operation of the interface.
Our athletes:
OnPropertyChanged (string) - Classic Call with Property Name Transfer
OnPropertyChanged (nameof) - the same as the previous one, but ...
OnPropertyChanged ([CallerMemberName]) - automatic determination of the property name
OnPropertyChanged (() => Expression) - passing an expression with a property
SetProperty <T> (ref T storage, T value, [CallerMemberName]) - hybrid
ObservableObject <T> - astudent told us about this
AOP - proxy generated by Unity, implementation from the past topic
(Coloring snails - the most interesting, detrimental effect of care in the frontend)
Running will happen in bags, for this each participant will be signed on PropertyChanged (empty static method), and will also implement a common interface, at this stage special attention is paid to participant No. 6, due to his innate mutations. If the interface can still be screwed up, then you will have to subscribe through DependencyPropertyDescriptor, he decided to show off. The track is a cycle of 10 million for each participant.
')
On your marks! Attention! Go!
The thing is not fast, you have to wait.
...
...
The experiment was conducted several times and the results do not differ approximately.
| 10,000,000 | 1. string | 2. nameof | 3. CallerMemberName | 4. Expression | 5. SetProperty | 6. ObservableObject | 7. AOP |
|---|---|---|---|---|---|---|---|
| Secons | 0.129 | 0.13 | 0.121 | 9,016 | 0.372 | 4,248 | 22,643 |
Rewarding
Snails 1,2,3 deservedly get the first place!
The second snail number 5, not much fell short
Bronze deserved goes to non-standard solution number 6
Next come the expressions.
And the snail master of sports closes the whole thing, reflection has ruined him.
Summarizing.
Obviously, to achieve maximum speed, you need to take tools from the 1,2,3 family. Using the application will slow down the application completely, but of course a non-optimal solution was used, you can optimize the reflection by creating delegates, saving 3 seconds, but this will not change the overall picture.
And now in fact! Using any of the implementations does not affect performance. 10 million calls take 25 seconds, which means that for a second you need to make 400k calls for a second! 400k , if suddenly this happens VM need to be dissolved in acid, without grief and regrets.
PS saving nanoseconds in such cases is useless, as a rule, most performance problems lie not only in technologies, but also a fairly large share in their curved usage.
Next without words ...
Source: https://habr.com/ru/post/282648/
All Articles