Large diagram performance

We are using GoJS v1.2.4 in our production environment.
One of our customers has created a tree with more than 12000 (sigh) nodes and as you might know we are running performance issues.
We know that performance is variable in javascript world, depends on the browser, on the machine where the browser are installed and so on.
But I wanna some guidance from people that maybe already run some of these problems.
I try to find how to load the tree partially (maybe this helps us) but I can’t found how to do this on the documentation.
My idea is try to make like facebook behavior, when you scroll down or lef we try to get more itens on the tree.

Any help are welcome,
thanks for the attention.

I think you want to use virtualization. This requires more work for you than normal, since more stuff has to be done with model data.

If you don’t need fancy TreeLayout options, you could use the Virtualized Tree sample in version 1.3. That sample shows a tree of 123456 nodes (more than 100 thousand!). But this is an extreme form of virtualization. The TreeModel has 123456 node data objects in it, but the Diagram typically only has at most a few hundred Nodes in it at a time.

If you really want to use TreeLayout, take a look at the Virtualized Tree Layout sample. This handles fewer nodes, but a tree of 12345 nodes is no problem.

Hi Walter,

Thanks for your answer. These links shows us that there are a solution for our question.
I’ll try to implement one of them. I just want to understand about what you call “fancy” options. Angle, layerSpacing, nodeSpacing, sorting, comparer. Are they the “fancy” options?

Look at the script for the (simpler) Virtualized Tree sample. It implements its own tree layout with a simple recursive tree walk. It is trivial to adapt that code to get similar effects to the TreeLayout properties layerSpacing and nodeSpacing and angle == 90. I suppose you could adapt that code to do sorting too, but that would require some work. Handling angle == 180 or angle == 270 ought to be easy too.

The crucial task when adapting the virtualization code is to implement correct computations for the size of a Node given a node data. That code is commented with:
//!!!???@@@ this needs to be customized to account for your chosen Node template

I’m trying to adapt the second solution to our environment. But my model is a little different from the model that you’ve used on the sample.

        myTreeModel =
          $(go.TreeModel,
            { // we use single character property names, to save space when rendered as JSON
                nodeKeyProperty: "k",
                nodeParentKeyProperty: "p"
            });  // must match the TreeModel used by the Diagram, below

then I decided to use:

myTreeModel = new go.TreeModel();

My model looks like:

[
        {
                "key":"15227",
                "say":"Nova sequência",
                "parent":"",
                "type":"Unear.RuleType.Sequential",
                "ruleLinkIndex":""},
                ...
]

But when they pass through this place:

this.focus = new go.Point(val.bounds.width / 2, val.bounds.height / 2);

The “bounds” value is undefined and then there are and uncaught type error when I try to access width and height. I think that I’m instantiating the wrong object for my tree model. Can you help me with this?

In my previous reply I said that you had a crucial task to do, marked with a comment. That is exactly what you need to do – give the node data a “bounds” property that accurately represents its size when it is instantiated as a Node. The position (x, y) doesn’t matter since the TreeLayout does not depend on it.

Sorry, I saw this later, because I’m getting data from my API, then I erase that loop from my code. After I adjust that loop, looks like it’s working, I put the two counters from your sample on my app and I’ve got this result: “Node data in TreeModel: 12465. Actual Nodes in Diagram: 0.”
When I scroll down and left the “Actual Nodes in Diagram: 0.” gets updated but always end in “0”. Maybe you have some insight about something more I left behind.

First I would check that your model has the right data. I'm talking about "myTreeModel". Is 12465 the right number? Look at the individual node data and make sure that it has all of the properties that it needs -- your app's info plus the key and the parent key and the bounds.

Yes, the correct number is 12465, I know that looks like a joke with 12345, but just looks like.
About the properties still the same as before plus the “bounds” info.
Any other ideas?

And do the “bounds” Rects have reasonable values for x,y,width,height? I guess at the time that you are showing this debug information the VirtualizedTreeLayout has not yet had a chance to run, so I assume the x,y values will be zero.

But you should also check the model data once the diagram is finished initializing.

If all of the model data is correct, then maybe the onViewportChanged method isn’t properly creating nodes in the Diagram.model from the data in the myTreeModel, depending on the position of the viewport.

Also, are you using go-debug.js and checking for messages in the console?

Hi Walter, I think that the virtualization is working ok.

Thanks for your support!

That’s good.

You never did say how long it took the page to display before. And how long does it take now?

Before the Diagram take almost 30 seconds after the data arrive from the server.
After 2 seconds.

This part if fully functional. Now I just need to adapt all the other functions to work with it. Big smile