This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Jason, This is my next challenge, I've noticed that there's a severe slowness when moving a node with more than 50 instances or so. What I'd like to achieve is smooth performance until 100 connections per node. I've paused the debugger while the UI freezes and i can see it spends time in many methods of Mindscape. Caching intersections and more. I'm using a straight line path finder so path finding should be super quick, my test was with the linear path so this should also be the easiest so what i'm suspecting is that there's so much things being done by mindscape the affect the performance. What are the intersections? What are you doing with them? We are data-virtualizing the connections, so i'm trying to udnerstand if i even need it. Is there anything you think you or I can do to improve the performance. At this stage I'm experimenting so even if it means i need to go to your code and make changes I'll do that, but I need some guidance or a starting point. I'm also noticing slowness when relocating a group on instances that have connections connected between them, the thing here is that aren't so many connections total in the group and it is still relatively slow. Is it possible that there's something there that doesn't work at O(n), cause with the number of connections i have it should be very easy for the diagram to be able to deal with 20 or so connections. I need help. The performance as is isn't good enough for us. We will do whatever we need to make it better, even on the expense of making changes ourselves. Unless you give me some hint my next step will probably be to profile it and see which methods are consuming most of the time. Thanx, Gili |
|
|
Hi Gili, Caching intersections is simply used for optionally displaying bridges over intersecting connections. You can see a demo of this here: http://www.mindscapehq.com/blog/index.php/2012/12/12/just-released-wpf-diagrams-3-0/ You shouldn't need this, and so fortunately, you can turn off the intersection caching which should save a lot of performance. Set the CanCalculateConnectionIntersections property on the DiagramSurface to false. -Jason Fauchelle |
|
|
Jason, So I gave it a try and the difference is dramatic! In fact, I kind of missed your reply and started debugging it myself, I ended up identifying method UpdateConnectionBuckets in class DiagramGrid to be the one who causes the slowness and it immediately prompted to me that I can set it to false. But then I tried disabling the entire code in this method (downloaded the source code, commented all code under method UpdateConnectionBuckets and recompiled it) - the improvement is even more dramatic(!), the diagram becomes way much more responsive to everything. I don't know exactly what are the segment buckets used for but it appears to create a load on the calculation and affect the overall performance significantly. When I tried the remove all code in this method (UpdateConnectionBuckets) I got into situations where connections wouldn't show if their originating node is virtualized (outside the viewport). Is there anything you can do to improve the non-intersections-related code, meaning the segment buckets related code? What are the segment buckets and what are they used for? Maybe if I understand better what the code is doing I'll be able to take a more wise decision about whether I need this or not or maybe suggest a way to improve it. Thank you, I really appreciate your help. Gili |
|
|
Hi Gili, The connection segment buckets are used for virtualization. When the DiagramSurface is told to render all nodes and connections within an arbitrary viewport, it needs to quickly find what connections are within the viewport, without checking every segment of every connection to see if each connection is at least partially within the viewport. The DiagramGrid listens to when connections are updated, and maintains which 'buckets' each connection is within which are later used to quickly query what connections are within the viewport. (Hence why when you disabled it, connections sometimes didn't show). I've made a performance improvement which simply disables the connection bucket update logic which is called far to aggressively when a node is moved. When the node is let go, only then will the connections be updated. In my performance test projects, this is working extremely well. This update will be available in the next nightly build. Let me know how it goes. -Jason Fauchelle |
|
|
Sounds perfect! :-) Next nightly build? |
|
|
Yes, this will be in the next nightly build. -Jason Fauchelle |
|