5 ms·

Rendering "thousands" of anything is usually not how you impress people. The scheduler is still cool though.

by fyp 7y ago

crooked-v 7y ago
I suspect you never had to deal with the days of AngularJS, where just rendering a large table-style view with a thousand interactive elements could slow browsers to a crawl.
- crimsonalucard 7y ago
  I think the comment is referring to the state of the front end in context of computing in general. In a broader context those metrics are pathetic. Your OS for example has UI performance light years faster.
Jasper_ 7y ago
Yeah, I'd say around the order of ~10k items is when an O(n^2) algorithm gets noticeably slow. "Thousands" is a shockingly weak payoff for all the effort. edit: and the real innovation here appears to be writing a multi-threaded scheduler. You should not need to spin up multiple threads to handle 2,000 objects. Something is going seriously wrong perf-wise here.
- c-smile 7y ago
  > O(n^2) algorithm gets noticeably slow. What algorithm? If that's about diff/reconciliation of DOM/VDOM then it is worse than that - O(n^3).
  - forrestthewoods 7y ago
    Can you point me to a good resource on what the n^3 process is? It’s not intuitive to me why it’s so, ahem, complex. Thanks! :)
    - fyp 7y ago
      I think he's way off on the complexity. He might be confusing it with text diffs where you need to find the longest common subsequence for the shortest possible diff but that is still O(N^2). If you are just diffing a list with unique ids (like react child nodes are, with their required key prop), it's just a set intersection which is linear. I can see it being a bit more complex if you need to track how nodes move across different parents. But it seems like react doesn't handle this: https://github.com/facebook/react/issues/3965# https://github.com/facebook/react/issues/3965#
      - deleted 7y ago
        [deleted]
      - baddox 7y ago
        The O(n^3) is to compute the minimum set of operations to transform one VDOM tree into another VDOM tree. React apparently uses simple heuristics to generate a diff in linear time. https://reactjs.org/docs/reconciliation.html https://reactjs.org/docs/reconciliation.html
  - ex3ndr 7y ago
    VDOM is O(n).
- dmix 7y ago
  I was pretty surprised at how my large Vue 2 form ground to a halt when I used it with 1-2 thousand objects. Mostly via many layers deep of small nested JSON objects which grow exponentially really fast ... because customers like jamming as much data as possible into a single HTML page's form instead of breaking it up across multiple forms/parent objects like we intended. Beyond work-arounds like pagination/hiding data, I've found the best solution is being careful with what data is marked as Observable/reactive and tracked by Vue for changes...which in Vue 2 is the automatic default behaviour where everything put it into data()/computed/Vuex or elsewhere is monitored. Then on top of that functionality which updates tons of rows at once (for example drag and dropping a row which then updates { order: n } for a hundred objects) then resulted in mini-freezes/slow downs. Crawling through dev tools memory captures never helped much because Vue is already extremely async/concurrent, so there was never one big slow thing to refactor - the problem was many thousands of small things that turned into one big slow thing. Vue 3 (surprisingly) helped me solve this problem, not by adding some extra concurrency to the view layer, but by making all the data default to a simple JS module, instead of a big options interface in Vue 2 where everything in Observable by default, and instead you explicitly mark which stuff should be reactive and watched. I managed to reduce the number of observed objects by 50-75% in some cases which got rid of any slow-downs. This of course was a rare use-case and not a knock on Vue, most people aren't managing hundreds of objects in a single HTML UI/form but it also wasn't very extreme either - just a modern web-based data-heavy B2B software requirement. Not all of it is do to the inherent framework design either but about how you use it + having good best-practices and defaults. I'm sure there was ways to do the same in Vue 2 but being the default approach significantly helps organize the code in a performant way. Only the data which needs to be reactive will be reactive and everything else is simple fast JS objects.
  - honopu 7y ago
    Use object.freeze in your mutation.
    - dmix 7y ago
      Yeah that was what I was started doing initially before switching to Vue 3. It gets aesthetically ugly pretty fast when every time you declare a variable (or more importantly flagging subsections of bigger objects) you have to put Object.freeze in front of it x100. And make sure any data inserted indirectly into an object afterwards gets frozen as well. I'd much rather the default be non-observed and the reactive data is explicitly marked, instead of the opposite. Which is a surprisingly under-reported evolution in Vue 3.

Rendering "thousands" of anything is usually not how you impress people. The scheduler is still cool though.

by fyp 7y ago

Rendering "thousands" of anything is usually not how you impress people. The scheduler is still cool though.

I suspect you never had to deal with the days of AngularJS, where just rendering a large table-style view with a thousand interactive elements could slow browsers to a crawl.

crimsonalucard 7y ago
I think the comment is referring to the state of the front end in context of computing in general. In a broader context those metrics are pathetic. Your OS for example has UI performance light years faster.

Jasper_ 7y ago

Yeah, I'd say around the order of ~10k items is when an O(n^2) algorithm gets noticeably slow. "Thousands" is a shockingly weak payoff for all the effort. edit: and the real innovation here appears to be writing a multi-threaded scheduler. You should not need to spin up multiple threads to handle 2,000 objects. Something is going seriously wrong perf-wise here.

c-smile 7y ago
> O(n^2) algorithm gets noticeably slow. What algorithm? If that's about diff/reconciliation of DOM/VDOM then it is worse than that - O(n^3).
- forrestthewoods 7y ago
  Can you point me to a good resource on what the n^3 process is? It’s not intuitive to me why it’s so, ahem, complex. Thanks! :)
  - fyp 7y ago
    I think he's way off on the complexity. He might be confusing it with text diffs where you need to find the longest common subsequence for the shortest possible diff but that is still O(N^2). If you are just diffing a list with unique ids (like react child nodes are, with their required key prop), it's just a set intersection which is linear. I can see it being a bit more complex if you need to track how nodes move across different parents. But it seems like react doesn't handle this: https://github.com/facebook/react/issues/3965# https://github.com/facebook/react/issues/3965#
    - deleted 7y ago
      [deleted]
    - baddox 7y ago
      The O(n^3) is to compute the minimum set of operations to transform one VDOM tree into another VDOM tree. React apparently uses simple heuristics to generate a diff in linear time. https://reactjs.org/docs/reconciliation.html https://reactjs.org/docs/reconciliation.html
- ex3ndr 7y ago
  VDOM is O(n).
dmix 7y ago
I was pretty surprised at how my large Vue 2 form ground to a halt when I used it with 1-2 thousand objects. Mostly via many layers deep of small nested JSON objects which grow exponentially really fast ... because customers like jamming as much data as possible into a single HTML page's form instead of breaking it up across multiple forms/parent objects like we intended. Beyond work-arounds like pagination/hiding data, I've found the best solution is being careful with what data is marked as Observable/reactive and tracked by Vue for changes...which in Vue 2 is the automatic default behaviour where everything put it into data()/computed/Vuex or elsewhere is monitored. Then on top of that functionality which updates tons of rows at once (for example drag and dropping a row which then updates { order: n } for a hundred objects) then resulted in mini-freezes/slow downs. Crawling through dev tools memory captures never helped much because Vue is already extremely async/concurrent, so there was never one big slow thing to refactor - the problem was many thousands of small things that turned into one big slow thing. Vue 3 (surprisingly) helped me solve this problem, not by adding some extra concurrency to the view layer, but by making all the data default to a simple JS module, instead of a big options interface in Vue 2 where everything in Observable by default, and instead you explicitly mark which stuff should be reactive and watched. I managed to reduce the number of observed objects by 50-75% in some cases which got rid of any slow-downs. This of course was a rare use-case and not a knock on Vue, most people aren't managing hundreds of objects in a single HTML UI/form but it also wasn't very extreme either - just a modern web-based data-heavy B2B software requirement. Not all of it is do to the inherent framework design either but about how you use it + having good best-practices and defaults. I'm sure there was ways to do the same in Vue 2 but being the default approach significantly helps organize the code in a performant way. Only the data which needs to be reactive will be reactive and everything else is simple fast JS objects.
- honopu 7y ago
  Use object.freeze in your mutation.
  - dmix 7y ago
    Yeah that was what I was started doing initially before switching to Vue 3. It gets aesthetically ugly pretty fast when every time you declare a variable (or more importantly flagging subsections of bigger objects) you have to put Object.freeze in front of it x100. And make sure any data inserted indirectly into an object afterwards gets frozen as well. I'd much rather the default be non-observed and the reactive data is explicitly marked, instead of the opposite. Which is a surprisingly under-reported evolution in Vue 3.