Nodes with more than 200 children are slow about angular-tree-control HOT 13 CLOSED

Angular ng-repeat is known to cause performance issues on large collections.
I guess the solution is to drop ng-repeat completely and instead use a custom tree building approach. The big challenge is observation on the tree data (that ng-repeat manages) which is the part that takes most of the performance penalty.

It is great to hear that angular-tree-control can hold 65000 entries, and sad to hear about the 100-200 entries limit per node. Maybe we can have a partial view of a node children? show the children in using paging or something?

I will have another look at how to improve angular-tree-control performance. What will help is if you can send me a sample (HTML file) with a huge tree that causes those problems.

from angular-tree-control.

I'm also facing some severe performance issues with only ~600 nodes and a relatively flat tree (max. depth 3-4). Opening the tree takes almost 7-10 seconds on a Core i7 desktop machine with Chrome/FF as the browser. It's sad, because the tree component is otherwise excellent.

from angular-tree-control.

If you check the directive there is a function call in ng-class as headClass(node). It is called automatically whenever there is a render or event is trigger in your DOM. It will degrade the performance as you grow your number of nodes.

from angular-tree-control.

I can see an option to optimize the headClass(node) method. it is not a simple thing to do, as it requires caching the different strings generated there as well as clearing the cache when options is updated. will try and find the time for it during the next month

from angular-tree-control.

I was able to dramatically speed up expansion of a branch node with a large no. of leaf nodes by adding an isLeaf check to the treeTransclude directive code...

if (!scope.options.isLeaf(scope.node)) {
    angular.forEach(scope.expandedNodes, function (node, id) {
        if (scope.options.equality(node, scope.node)) {
            scope.expandedNodes[scope.$id] = scope.node;
            scope.expandedNodes[id] = undefined;
        }
    });
}

from angular-tree-control.

Thanks for the idea - it is now part of tree control 0.2.2

from angular-tree-control.

We are also using the latest code and still have the same problem in opening or closing a node with many sub-children. I sae the cintimedia idea is already inside our code, so we are updated.

from angular-tree-control.

I know the current state is not sufficient. Some additional ideas to improve performance are to cache different string concatenations that are done in some of the methods, and invalidate the caches using $watch on different options (basically, the custom classes and other such options).

I will try and find the time to work on this, but I am not optimistic for now. If any one of you has time and can send me a pull-request, given all tests pass, will merge it.

from angular-tree-control.

One performance issue with deep trees is the equal tests which works by deep copying. If each node has an id you can avoid these huge costs.

You may want to add such a method to the tree options:

        equality: function (a, b) {
            var res;
            if (a !== undefined && a.galleryId === undefined) {
                alert("bad");
            }
            if (b !== undefined && b.galleryId === undefined) {
                alert("bad");
            }
            if (a === undefined && b === undefined) {
                return true;
            }
            if (a === undefined || b === undefined) {
                return false;
            }
            res = (a.galleryId === b.galleryId);
            return res;
        }

from angular-tree-control.

Is there any chance to have the unpagination behavior like this:
http://binarymuse.github.io/ngInfiniteScroll/
As an alternative to the load all at once approach?
My users often upload 1000+ images in the same directory so I don't really need to display everything at once if possible, could you point me in the right direction and I could get started on this?

from angular-tree-control.

What I currently suggest that is an easy work around:

var RealTree; // has all children, hundreds or thousands
var viewTree; // has the n first children only by default

When you view the viewTree and reach the second half of the last n children, (i.e looking at item n/2 +1 or greater) you implicitly trigger folder xyz to extend it's children array with another n children. This way when you open a new directory, you get a snappy response but if you scroll down a bit, it loads more items from a local cash so if you get any slowdown it's only once you actually browse through the children of that specific folder.

What do you think? I could get started if you point me in the right direction.

from angular-tree-control.

Here is how I would do this with a flat ng-repeat in the view:

http://plnkr.co/edit/1b5nTcvkTSUWNmxKtCAB?p=preview

from angular-tree-control.

fixed

from angular-tree-control.