Performance considerations for dropping and connecting 2000+ shapes on the page

[Visisthebest]

When writing some VBA code to drop and connect more than 2000 shapes on a page at once, what are some performance considerations to keep in mind?

Please note that information about these these shapes (text, to which shapes they connect) are stored in Excel but I pull in the entire sheet into a VBA array before I start dropping the shapes on to the shape sheet. That already makes a big difference in performance.

The diagram is a somewhat customized Cross-functional flowchart, there can be more than two outgoing connections on a shape but typically there will be one outgoing, one incoming.

Visio does not need to do any layout for the shapes I drop, I’ve written a custom layout routine to figure out the custom layout I need and the exact position of the shapes, in fact good to know how to suppress any (potential) auto-layout behavior also very useful.

I do want to leave the line routing behavior to Visio, so Visio figures out how to route the line depending on the settings the VBA code uses. (and then should re-set to the current user settings after it is finished)

Thank you for any tips and guidance you can provide!

[Paul Herber]

There was a related question very recently:

http://visguy.com/vgforum/index.php?topic=8879.msg38984;topicseen#msg38984

Dropping 2000 shapes will make Visio slower, how much slower depends on your CPU speed, how many cores, memory size etc. The complexity of the shapes is also significant, very simple shapes (e.g. plain rectangles) will be very much quicker than complex grouped shapes containing images.

[Visisthebest]

Thank you Paul good to know this is expected behavior, when doing some tests I did notice (but not measure) that Visio doesn’t become quite so sluggish if I have shapes in a hidden layer on the page, these seem not to make Visio much slower but when I show these shapes again Visio slows down. Is that your experience also?

[Paul Herber]

I didn't try that, but that does make sense. Less work for Visio to do when showing the shapes..

[Visisthebest]

Yes good to know this may be useful for speeding up code that drops several thousands of shapes at once, but I have to think about the order in which shapes are dropped, connected and then hidden.

Does moving some VBA code in to a VSTO addin (I have kept the code as compatible as possible with VB.NET, avoiding things like variants, explicitly setting ByRef/ByVal etc) help performance or when dropping lots of shapes could it actually be slower than VBA?

[Paul Herber]

Does moving some VBA code in to a VSTO addin (I have kept the code as compatible as possible with VB.NET, avoiding things like variants, explicitly setting ByRef/ByVal etc) help performance or when dropping lots of shapes could it actually be slower than VBA?

Pass.

[Visisthebest]

Ok thank you Paul!

[Visisthebest]

Dropping 2000 shapes will make Visio slower, how much slower depends on your CPU speed, how many cores, memory size etc. The complexity of the shapes is also significant, very simple shapes (e.g. plain rectangles) will be very much quicker than complex grouped shapes containing images.

So end users could also significantly speed up working with huge diagrams (unfortunately we have a 5000+ shape cross-functional flowchart-type diagram to deal with now) by upgrading to a new 4-core Whiskey Lake notebook with 16GB memory!

On a machine with ample memory, does using 64 bits Visio make a difference with huge diagrams?

[Nikolay]

Does moving some VBA code in to a VSTO addin (I have kept the code as compatible as possible with VB.NET, avoiding things like variants, explicitly setting ByRef/ByVal etc) help performance or when dropping lots of shapes could it actually be slower than VBA?

Moving code to VSTO will only make it slower, because in addition to the Visio execution time you will have interop time on the top (to convert parameters/results to .NET types, and to construct proxy objects for .NET)

You can check this article on performance tips for example:
https://blogs.msdn.microsoft.com/mailant/2004/09/22/dev-luv-visio-development-top-five-performance-tips/

Other than that, I'd recommend to stick with Visio 2010 (or below) for performance reasons (it appears to be times faster than 2013+)

[Visisthebest]

Ok yes thank you for the explanation, my mental model was too simple (vb.net is compiled, vba interpreted therefore vb.net faster).

Nikolay if I would put my custom layout calculation code in to a VSTO addin to take advantage of compiled code, what is the best way to run the layout code in the VSTO addin and pass an array of layout data back to the vba code (which will then drop all the shapes in the right place)?

I understand if I put an EV code signing certificate (Extended Verification) on VBA code in a stencil, most if not all users of the .vssm stencil won’t see a security warning or be blocked from using the macro-enabled stencil?

Thank you for all the guidance, your (Paul & Nikolay) and this forum is a lifesaver for the Visio beginner!

[Nikolay]

You can call VBA function from vsto and pass parameters. But keep in mind that this call is also a subject to interop. So it would not make sense to create wrappers for Visio functions. Anyways, I think it worth trying first in pure VBA, maybe you don't need VSTO.

You can also expose your .net object for VBA, VSTO supports this as well, performance is the same.

The security is controlled by user's admins. They can disable or enable your extension regardless of the signature actually (although with signature it is easier of course). Simply signing you stencil with EV certificate will not guarantee the absence of security warnings,.

EV is only relevant now if you want to sign device drivers, as far as I know. You get certificate on USB token (means that you need it to physically present every time you sign), and it's more expensive. Even the "green browser bar" and "instant reputation" are now gone, as far as I know.

[Visisthebest]

Thank you Nikolay for your information and guidance!