Diagram performance problem and tricks?

[Douglas]

Hi,

I'm using the Rad diagram to display a network of projects. These projects are linked together based on whether one project was copied from another project and so on. Therefore the diagram contains clusters of projects which are linked together. If a project was not copied from another project or is not then copied itself it doesn't appear in the diagram.

So the diagram is just really then a bunch of rectangles (projects) with links between the rectangles. All of this is read only, although the boxes are coloured differently depending on the properties of a project. I have custom tooltips for the rectangles. The boxes can be selected and some right click context menu actions can be executed on the project.

This works well for around 400 projects but doesn't scale if I have 1000 projects in the diagram or more. The diagram simply wont load. Our scenarios can be typically anything from 50 projects to possibly 2000 - 3000 projects.

This is implemented using the IGraphSource in the view model and creating the InternalItems and InternalLinks on the bound data. I've tried using a simple Sugiyama layout type in addition to the custom one i would normally use. This doesn't seem to help.

Are you aware of this performance limitation and is it expected? Have you any hints or tips so I can display more items in my diagram?

I notice when i step through the code I can get to the point where I call diagram.Layout but after this it hangs. I also note that during the process of adding to the observable collections of InternalLinks and InternalItems to the diagram prior to the layout call this takes 9 or 10 seconds for 5000 items. All the time is in the InternalLinks.Add call.

Any help would be much appreciated!

Thanks
Doug

[Zarko]

Hi Douglas,
I guess the layout performance really depends on the layout algorithm implementation - our Sugiyama layout works ok with about 500 links or less but it's really slow with 1000 link and more (the number of nodes doesn't really matter - the layout works ok with 4000 nodes and 500 links).
I'd like to ask you for some more information about your specific case so that we could help you better.
I've attached the sample project I used for testing so you could examine it.
We're looking forward to hearing from you.

Greetings,
Zarko
the Telerik team

[Doug]

Hi,

Yes this is exactly what i'm seeing. Have you plans to improve the layout algorithm to cope with more than 500 links?

By definition every project will be linked to another project. The best case scenario is that we could have half as many links as projects, but more normally the links number 3/4 of the number of projects because of the levels of copied project hierarchies.

I have just switched our implementation from the Northwoods Go Diagram offering which handled 2000 links + using a sugiyama layout.

I don't want to have to prevent the user visualising one or two thousand projects in the diagram if they wish.

Also have you any comment on the slowness of actually adding to internal links observable collection prior to the layout call which as you noted is also slow?

Doug

[Francois]

I have written a more elaborate explanation regarding scalability and performance of RadDiagram on the Orbifold's blog. The considerations therein are based on more than ten years of consulting in this domain, hence not an excuse with respect to the decisions we made while developing RadDiagram but an indication of what our product is within a broader (technical and business) context.

 

Hope this helps,
Francois
the Telerik team

[Douglas]

Hi,

Thanks for the reply.

I've just read the blog and appreciate the sentiment and considerations. The blog does make reference to visualising millions of pieces of data but in our case we really just need the capability to display 500 to say 2000 links - not really the same thing. To my mind these sorts of numbers seem reasonable and only reason I make reference to the other third party software is because it was possible to display this number of links. Presumably they are subject to similar limitations.

Currently i'll have to notify the user to further constrain the view which isn't ideal. Don't mistunderstand me, I think its a very nice component but would be great if the scalability for Sugiyama layout could be improved to cope with more links.

It would be helpful to put the limitations into the documentation.

Thanks
Doug

[Tina Stancheva]

Hello Douglas,

Thank you for getting back to us and sharing your feedback. We will definitely consider it when discussing performance improvements in the diagramming solution.

We will also make sure to add the limitations Francois discusses in the blog post in the RadDiagram documentation with the next week's documentation upload.

All the best,
Tina Stancheva
the Telerik team

[Yenting]

The link of the blog post (the Orbifold's blog) is not available anymore.

[Pavel R. Pavlov]

Hello Yenting,

Indeed the link is no longer available. However, that blog is not in our domain and this is why we cannot update the link.

Please accept our apology for the inconvenience caused.

Regards,
Pavel R. Pavlov
Telerik

 

 

[Shawn]

Here is the link to the original article: http://www.orbifold.net/default/diagramming-scalability-performance/

Shawn

[Shawn]

Sorry for missing the formatting on the link: http://www.orbifold.net/default/diagramming-scalability-performance/

[Yenting]

Thanks a lot for the link