Angular-tree-component: Performance regressions since 3.x

[chpasha]

Hi,

I've recently tried the current 3.3.0 version and compared to my current 2.8.2. I have a tree with about 3k nodes and the filtering speed in the older lib seems to be multiple times better than the new one. Showing/hiding deleted nodes - same story- the old one shows hides them immediately, the new version freezes for a second before showing the results. I also tried the virtual scrolling - doesn't work any better. Can anything be improved here? Maybe there are some "do" and "don'ts" that changed along the way? Seems like a huge regression to me :(

[adamkleingit]

Is there any difference between virtualScroll or not?
@chpasha Can you share your code?

Thanks

[chpasha]

Is there any difference between virtualScroll or not?

I didn't do any measurements, visually I could not notice any notable difference. I don't need it that much, since the node count is pretty constant and I was happy with the performance of the old version - it is imho a little bit challenging to have to define the container height explicitly. But the difference with the old version is significant.

Can you share your code?

it would be difficult since it is a commercial project. Actually I hoped to hear that it is a known limitation/regression/whatever since there were significant API changes under the hood as far as I can see. If I'm the only one to experience this kind of issue, I will have to investigate further which part of the code that was working fine with older version slows down the performance. If I can find the problem maybe I can reproduce it on a simple project.

[chpasha]

ok, I found the problem - seems like the treeModel.setIsHidden does a huge penalty hit to the performance if used too often - I was doing a tree search, additionally showning/hiding the nodes according to the current "show deleted" setting. The older library used isHidden field for showing/hiding and now it seems to be ignored so we have to call setIsHidden on treeModel explicitly which in turn slows down the search significantly. My workaround was to check first if nodes are already shown or hidden with treeModel.isHidden - actually, this is a point for performance improvement - you could check if the node with id is already hidden (or shown) before doing anything inside setIsHidden. What do you think? Anyway, showing/hiding nodes is slower in 3.3.x then before, but I could live with it since this operation is not as often as tree search.

[johaven]

Without talking about tree search i confirm a performance problem.
I open about 6 nodes, the last containing my node_modules (700 folders) and the process consumes between 60 and 100% CPU every time i scroll (i'm on core i7 ...)
I don't use virtual scroll, each node is loaded in async way.

[adamkleingit]

@chpasha I can add a setHiddenNodeIds function that will receive an array of node IDs. It should help because it will do all the calculations after setting all node IDs and not for each one.

@johaven I suggest to use virtual scroll, when we're talking about over 700 items, each one represented by around 10 DOM elements, it can get to 1,000 angular components and 10,000 DOM elements.
Can you try with virtual scroll and say if the problem persists?