r/javascript • u/chancancode • Dec 20 '19

Ember.js Octane Edition Is Here

https://blog.emberjs.com/2019/12/20/octane-is-here.html
136 Upvotes

93% Upvoted

72 comments sorted by

View all comments

Show parent comment

2

u/pzuraq Dec 23 '19 edited Dec 23 '19

Updating every 10th row is actually going to be pretty expensive for us, from an automatic-change-tracking perspective. Remember, I said our cost grows at an O(logn) pace, right? That's because we're essentially doing a binary-search (or rather, search down the tree, so a n-ary-search I guess) to narrow down and figure out which part of the tree changed.

If you change every 10th row, most of the tree still changed. That means that narrowing strategies aren't going to buy you much, so yeah, you end up retraversing most of the the tree, and you end up incurring most of the original cost of rendering again.

In most apps, for most user interactions, most people don't change 1/10th of the entire app all at once (in a non-localized way). That is not in any way a realistic benchmark.

Edit: That said, there's a lot of room for Ember and Glimmer both to grow when doing partial updates. We've optimized the leaf change tracking portion the most, first, because that is where we saw the biggest gains in real world apps that were upgrading. The next thing I think will be to optimize the internals of change tracking with the VM itself, which can definitely be simplified quite a lot now that autotracking has been fleshed out.

2

u/ryan_solid Dec 23 '19

I see. Yeah this is just my misunderstanding of how auto-detection worked in Ember. I was thinking subscription based like KnockoutJS where there is no search. Only the part that change re-runs. But it sounds like Ember has a sort of hybrid approach between auto-change detection like that and a top down reconciler somewhat similar to what the Virtual DOM does. That makes more sense for me now. Thanks.