We have a document that consists of over 6000 components with at least 20,000 links. It is usable (just) but on repainting after RescaleToFit() the memory is exhausted and a general freeze takes place. I know this is dependent on the resources available to the PC, the nature of the images used by the components etc. and fitting something this large isn't particularly useful.
However, we are facing customer requirements to create documents of 20,000 components. Is there a recognised limit to the size of a Document? Are we trying to do something beyond the reasonable limits of the tool? Given that under normal circumstances only a subset of those components will be visibile at any one time does the document size matter if zooming-in is kept under control?
If the individual components aren’t too complicated, that shouldn’t be a problem. Handling 100,000 top-level objects should have acceptable performance, as long as you aren’t trying to show them all at once.
Since it creates the nodes on demand, it starts very quickly. Scrolling is pretty good too. Dragging around a node is pretty snappy also.
If you do zoom out to show the whole grid, it will take time to construct all of the nodes and links. Dragging around a node (which is hard to see at such a small scale) is slow, but I think the performance is pretty good considering how many nodes and links are visible simultaneously. But if you try selecting several thousand objects at once and drag them around, you’ll definitely see the lag.
But if each of your components has hundreds of nested objects, you’ll probably have a lower effective limit. Still, if the components are distributed in space and your view is only showing a small fraction of them, responsiveness should be good.