Organization node performance

The application that I am working with uses goXam diagramming library to display a large organization node structure. In some organizations, we have more than 5000 nodes. When doing saving and loading it takes a very long time and I feel most of the time it is goXam. Is there anything we can do to improve the performance in this situation?

In particular, we got an “Out of Memory Exception” when we trying to save this organization to database. What can we do to reduce the memory usage and maximize performance?

I suspect that the problem is that GoXam depends on the FrameworkElements of WPF or Silverlight (which are you using?) and those are inherently slow to create and large in memory usage. GoXam only really takes up time when routing links or performing layouts. But if you are using TreeLayout, that’s pretty fast, so I doubt that that is the problem.

The main course of action is to implement some kind of virtualization. Have you seen the VirtualizingTree sample?

Thank you for your reply. Our application is using goXam for SilverLight. I will take a look at the VirtualizingTree sample.

Some projects have more than 6000 organizational nodes in the diagram. What is the nomal time to loading and rendering a diagram of this size? Right now, it is taking too long 10-20 minutes sometimes.

Well, if you really need to show all those nodes at once, yes, it will take a long time. But if you are able to use virtualization, then the experience should be much better. For example, when I open up the Virtualizing sample, it takes a couple of seconds to create a model of 9999 nodes, perform the VirtualizingTreeLayout, and then realize and show a few hundred Nodes and Links in the viewport.

The normal layouts such as TreeLayout depend on the Nodes and Links already existing, but that is unreasonable when it takes so long to create all of those FrameworkElements in Silverlight or WPF. That is why a custom layout, VirtualizingTreeLayout in this case, is required. Obviously you gain a lot in performance, but it does require knowing how large all of the nodes will be without actually creating them.