You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically, I put together the most complicated scenario I could: Filter, Sort, and Page, with items that are fully mutable (meaning we need to handle single-item refreshes) and with observable state for all operators (meaning we need to handle full re-filter, re-sort, and re-page operations).
Each operator is implemented as a proof of concept, rather than optimally, using a plain collection to track upstream items, and a change-aware collection to track downstream items. E.G. the .WhereItems() operator has unfilteredItemStatesByKey and filteredItemsByKey.
Even with these naive implementations (.WhereItems() in particular is responsible for almost all of the bottlenecks, it performs very poorly with large resets), we can see drastic improvements over baseline DD.
Method
InitialItemCount
MutationCount
Mean
Ratio
Allocated
Alloc Ratio
DynamicData
10
10
225.98 μs
1.00
190.95 KB
1.00
DynamicDataVNext
10
10
78.81 μs
0.35
96.69 KB
0.51
DynamicData
10
100
1,005.35 μs
1.00
827.89 KB
1.00
DynamicDataVNext
10
100
396.90 μs
0.39
437.58 KB
0.53
DynamicData
10
1000
7,779.01 μs
1.00
5867.75 KB
1.00
DynamicDataVNext
10
1000
3,270.35 μs
0.42
3330.13 KB
0.57
DynamicData
100
10
944.48 μs
1.00
931.71 KB
1.00
DynamicDataVNext
100
10
435.14 μs
0.46
658.37 KB
0.71
DynamicData
100
100
1,769.13 μs
1.00
1606.21 KB
1.00
DynamicDataVNext
100
100
747.36 μs
0.42
966.22 KB
0.60
DynamicData
100
1000
8,293.80 μs
1.00
6588.69 KB
1.00
DynamicDataVNext
100
1000
3,844.70 μs
0.46
3828.35 KB
0.58
DynamicData
1000
10
6,286.88 μs
1.00
4988.21 KB
1.00
DynamicDataVNext
1000
10
14,665.62 μs
2.33
20557.26 KB
4.12
DynamicData
1000
100
18,004.71 μs
1.00
10322.29 KB
1.00
DynamicDataVNext
1000
100
20,800.48 μs
1.14
24324.31 KB
2.36
DynamicData
1000
1000
52,584.85 μs
1.00
37875.97 KB
1.00
DynamicDataVNext
1000
1000
45,030.18 μs
0.86
38091.94 KB
1.01
Individual Operator Profiling
For each of this, I basically took the full query above and trimmed it down to just one operator. I then calculated "Adjusted" measurements for each benchmark by subtracting out the measurement from the equivalent "InitialResetOnly" benchmark (for "IntiialResetOnly" the "SubscriptionsOnly" measurement is subtracted), as a way to roughly eliminate the overhead from setup and binding, and estimate the impact of just the operator in question.
Fully Dynamic Query Binding with ViewModel items
Basically, I put together the most complicated scenario I could: Filter, Sort, and Page, with items that are fully mutable (meaning we need to handle single-item refreshes) and with observable state for all operators (meaning we need to handle full re-filter, re-sort, and re-page operations).
Each operator is implemented as a proof of concept, rather than optimally, using a plain collection to track upstream items, and a change-aware collection to track downstream items. E.G. the
.WhereItems()
operator hasunfilteredItemStatesByKey
andfilteredItemsByKey
.Even with these naive implementations (
.WhereItems()
in particular is responsible for almost all of the bottlenecks, it performs very poorly with large resets), we can see drastic improvements over baseline DD.Individual Operator Profiling
For each of this, I basically took the full query above and trimmed it down to just one operator. I then calculated "Adjusted" measurements for each benchmark by subtracting out the measurement from the equivalent "InitialResetOnly" benchmark (for "IntiialResetOnly" the "SubscriptionsOnly" measurement is subtracted), as a way to roughly eliminate the overhead from setup and binding, and estimate the impact of just the operator in question.
Keyed Filtering
Keyed Sorting
Sorted Paging
The text was updated successfully, but these errors were encountered: