Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling large number of children #84

Open
ghost opened this issue Jan 23, 2019 · 10 comments
Open

Handling large number of children #84

ghost opened this issue Jan 23, 2019 · 10 comments

Comments

@ghost
Copy link

ghost commented Jan 23, 2019

Hi,

I'm trying to render tree structures having largen numbers of direct children (several thousands).
Rendering times are very slow then. I think the reason for this is the way getFlattenedTree is implemented.

@diogofcunha
Copy link
Owner

Hi @Baehn.

I believe the tree supports a reasonable number of child nodes, but yes the bottleneck is getFlattenedTree.

I will be releasing some news on a more performant approach over the next couple of days

@diogofcunha
Copy link
Owner

Hi @Baehn

Just did some work on this and by managing more state could make some fantastic improvements.

This work is still unstable, so it isn't available on npm just yet, will be in the next few days.

I change https://diogofcunha.github.io/react-virtualized-tree/#/examples/large-collection example to use this Unstable tree and it is rendering around 1.7 Million nodes and has you can see updates in the tree are really fast.

Hope this will help you.

@ghost
Copy link
Author

ghost commented Feb 2, 2019

great! Have you tried trees with many direct childrens? I have changed the implementation of getFlattenedTree and the filtering method in FilteringContainer and got massive improvements. I replaced reduce with an simple recursion using an accumulator (I think the bottleneck is the creation and concat of arrays). If your are interested I can post my implementation here.

@hieuhlc
Copy link

hieuhlc commented Feb 19, 2019

@Baehn @diogofcunha from the ECMAScript 2015 document, reduce includes lots of unnecessary steps that we can skip to achieve better performance. So I'm totally agree we should rewrite it with simple for loop.

Ref: https://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.reduce

Performance test can be found here:
https://hackernoon.com/javascript-performance-test-for-vs-for-each-vs-map-reduce-filter-find-32c1113f19d7

@hieuhlc
Copy link

hieuhlc commented Feb 19, 2019

@diogofcunha may I ask what is the Unstable in UnstableFastTree, and when are we going to have it stable?

@diogofcunha
Copy link
Owner

Hi @Baehn.

I'm aware of performance implications with reduce, although most times it doesn't really matter.

The new tree implementation (Unstable) is written with for loops and an improved seek and it's much faster.

Yes, there will be a stable version, I just need to find the time to play around with it a little bit more and make sure it's good enough to ship.

@robintindale
Copy link

Any update on when UnstableFastTree will be on npm?

@maxnowack
Copy link
Contributor

I'm also interested in the stable version of UnstableFastTree 🙂
@diogofcunha Is there anything I can help you with?

@DawnL6
Copy link

DawnL6 commented Nov 6, 2019

I see only exporting Tree and {selectors, renderers, constants, FilteringContainer} and so on. But UnstableFastTree is not yet, is this waiting for a stable version or how will I use it?

@abhishiv
Copy link

abhishiv commented Feb 8, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants