Shape creation slow

[wapperdude]

Hmmmm.  Out of curiosity, couldn't have just written a V2007 version?  My understanding is that both V2010 and V2013 can read a V2007 file.  Also, I think both version will save to the older format.  Finally, it would seem that as far as generating the file, shouldn't make any difference whether it's 32B or 64B.  It's the actual Visio engine that leverages that difference.  I could be wrong on that, certainly not territory I'm very familiar with.

It's just a rhetorical thought...no need to answer.

Wapperdude

[daihashi]

I know you said it was rhetorical, but I like make follow up posts for others who might have similar problems and happen come across my thread in the future. I bet everyone here just thought I enjoy talking to myself.. haha  . Anyway, to answer your questions (for future people who may stumble across this thread):

There is certain VBA that either doesn't work in 2007, or doesn't work as well as it does in 2010; the same is true for 2010 and 2013. I mean for the most part, everything is compatible across all versions, but there are some differences. My original approach was to write 1 version of code, but then I had problems related to the different versions that people run. I would have to look through my scratchpad/notebook to see what specifically sent me down this path of writing code that could handle these 3 versions of Visio *optimally*. Automation is a heavy burden on my documents, or more accurately... because I'm a novice, it is probably actually the approach I took to automating. Hopefully I will be able to refine this even further in my future releases, but the document now performs fairly decently since I've found a workaround for this bug in Visio 2013.

Also 32bit vs 64bit code is relevant to me since I call APIs, have my own event handlers, and a number of other things declared. I also think I had to modify portions of my code because certain references didn't work with Windows 8/8.1; but I don't remember specifically what I changed for that version of Windows... I only remember getting complaints from a handful of users who had Windows 8. If I wasn't doing these things then you're probably correct, there would be no reason to write code to handle 64bit operation.

[wapperdude]

Nice explanation.  Reminds me why I never went into IT related stuff.  Obviously, I had an oversimplified and incomplete vision.

[daihashi]

yep, which is completely my fault. My actual template is something like 100,000 lines of code; which I suspect is mostly due to the fact that I'm a beginner, I didn't want to force anyone to try to read through my sloppy coding .

In the first "automated" template I ever created; which I now laugh at the idea of calling that thing "automation", I didn't have many performance problems since it really didn't do too much. However, now that the document is truly automated it seems that some of the conditional logic that I've written throughout the document has bogged things down a bit. The performance hit isn't very noticeable in Visio 2010, but it was immediately apparent in Visio 2013.

It took me a few weeks to even realize that the issue was actually with Visio 2013 itself. I only upgraded to it recently when I was trying to troubleshoot issues with loading custom png's into the ribbon; which I  learned through testing that Visio 2010 will not load the images, but Visio 2013 works just fine... so I also maintain two UIs which load depending on which visversion is detected. Anyway, I never went back to Visio 2010 and I hadn't worked with the template in a few weeks, so I never related the problem to Visio and instead mistakenly blamed the corporate PC Image Load.

I'm just glad I got it worked out. I doubt anyone will have the problem I experienced, but just in case I wanted to be sure I documented my experience and troubleshooting methods for them to follow.

[daihashi]

Just an update; even after creating a series of collections, classes, and a number of other things... I managed to trim the code up to 20,000 lines. The tool does quite a lot; pretty close to a "Network Engineer in a Box" as you can get. So getting the code down this small using VBA is quite a feat. If portability wasn't a concern I would have just used another language.

Despite all this; performance on things like Drop/DropMany and SetFormulas is very slow compared to Visio 2010. I wish I could figure out why Visio 2013 is such a poor performer when compared against previous generations of Visio. I would not mind if it was a 1-2 second difference, but the performance difference is greater than 400-500%; which is a bit ridiculous.

I can live with it, but overall it seems like Microsoft has impacted the performance; at least as it relates to custom user made stencils.

[daihashi]

some will think this is a bit dramatic, but below is a list of time for one procedure that builds a set of labels for one of my shapes. Lately I'm debating having Visio draw these shapes instead, and set the various formatting cells the way I need them... pretty sure that would be faster; but using dropMany would be far more convenient if I could work out the performance issue.

This function only drops 7 shapes; aside from some coloring and text within the shape, these shapes have nothing particularly special about them. The times listed are in seconds. DropMany is the only portion that is excessively slow.

L3_Labels_and_status end of SHP variables  3.39590655914069E-04
L3_Labels_and_status end of DropMany 13.5527316370503
L3_Labels_and_status end of vsoCharacters 3.53539530767215E-02
L3_Labels_and_status end of SetFormulas #1 9.56679702923076E-03
L3_Labels_and_status end of SetFormulas #2 1.03561566427555E-02
L3_Labels_and_status end of SetFormulas #3 6.34294973575319E-03
L3_Labels_and_status end of SetFormulas #4 7.73451677909884E-03
L3_Labels_and_status end of SetFormulas #5 4.61299946993672E-03
L3_Labels_and_status end of sub 1.41634961476836E-02
L3_Interfaces 3.3901947952374
L3_IP_labels 8.45203410275017E-06
L3_Links 1.73450259175589
SET_devicePINY 2.28235106610336E-03

[daihashi]

I had some time today; and here is a comparison of the time it takes to draw and format all the shapes compared to the time it takes to use DropMany (see times from my post yesterday). This even includes inserting field values and binding them to shape data elsewhere on the page.

I will change most of my code to draw these shapes manually. I would have liked to have kept using masters and dropping them, but I prefer the performance gain over convenience; plus it's not such a problem for me anymore since I've developed my own update method that doesn't rely on updating document masters. For others, drawing all their shapes programatically may not be an option if they depend on using document masters to keep their shapes up to date.

Here are the times that were recorded by drawing these shapes, formatting them, and adding field values (instead of using dropMany). This now runs 13x faster; or to say it in a statement that is mathematically correct... it is 99.999996% faster over the previous run time.

L3_Labels_and_status end of SHP variables  2.4209040537163E-04
L3_Labels_and_status end of Draw Shapes 6.03716721625012E-07
L3_Labels_and_status end of vsoCharacters 5.91431086339943E-03
L3_Labels_and_status end of SetFormulas #1 7.43054540976065E-03
L3_Labels_and_status end of SetFormulas #2 8.4164148161743E-03
L3_Labels_and_status end of SetFormulas #3 5.61607480291668E-03
L3_Labels_and_status end of SetFormulas #4 7.39673727334965E-03
L3_Labels_and_status end of SetFormulas #5 4.87018279334897E-03
L3_Labels_and_status end of sub 0.011657769894579