I hate coming here when I have a problem/challenge.. I would much rather post because I have something incredible to contribute, but alas here I am again.
Due to various reasons; primarily to keep file size as small as possible, I have a document I am creating that generates various "stencils" based on a couple of very simple boxes that act as my master. In nearly all my shapes this isn't a problem; the time to draw most of them only takes about 2-3 seconds... could be better but this is acceptable considering how much of this I am doing through code.
However, there are a few "stencils" that I attempt to draw via VBA and they are pretty darn slow; even more frustrating, the slowness only happens on the corporate issued laptops... but not on my personal workstation at home (isn't that always the case?? It seems that companies love to kill the performance of the computers that they issue their employees).
To create one of these "stencils", a total of 60+ shapes are dropped... most of them the exact same shape. Initially it took about 45 seconds to create this shape on my corporate laptop; I then started using the dropmany method instead and this improved performance drastically, reducing the total time to 25 seconds.. which is still too slow. I then implemented the setformulas method and this further reduced it to 19 seconds on the corporate laptop.. better but still too slow. I've gone through the sub routine and changed a number of array data types to be integer instead of variant, and wrote out the arrays in a long format. I tried to remove duplicate calculations when possible. I even tried using doevents, and even tried manipulating the GetQueueStatus API to try to further reduce the size, but this did not improve or decrease the performance of the document.
Keep in mind that this may run very quickly if you are using a personal workstation with an SSD hard drive. If you have an older PC, or a corporate laptop that is heavily loaded with the typical windows 7 image and things like McAfee suite, then perhaps you will be able to replicate the slowness... I sure hope so, because I just can't seem to figure this problem out.
I would simply make the entire thing as a pre-made master... which is lightning fast, but this drastically increases the file size and our documents can be very detailed and have many pages, so keeping the file size as small as possible; even if it only saves a few kb per shape, is important to me.
I forgot to include the files.
Copy SMART[MASTERS]2.vss to your C:\temp directory, and then open "help[sadface].vsd".
When the document opens, right click on the second grouped shape from the top and select "Add Video Conferencing". This will add the shape that I am having problems with. The code for this shape can be found inside the SMART[MASTERS]2.vss file. I removed as much of the code as possible. Currently the "real" document I have is about 80k lines of code, but only because I haven't gone back and re-written most of my subs/functions into arrays and loops yet; I always write things out in long format before I finalize the code.
This version has substantially less; so many of the buttons and functions you see in the document won't work properly.. however, the "Add Video Conferencing" will work... which is all I care about.
There are 3 different subs, the first one is called "ADD_SERVICE_VC3"; this calls another sub called "service_formulas", and then after that "ADD_TABLE_VC3" is called. It is this last sub where all the heavy work is done, and also where the slowness occurs. Again, on my workstation at home this only takes about 3 seconds to add... but on my corporate laptop it currently takes about 19 seconds; which is far too slow to be usable.
Darn.. the files are slightly too big even though I stripped out most of the code and unused master shapes. I've provided a google drive link to the files instead.
Here is a link to the file named SMART[MASTERS]2.vss
https://drive.google.com/file/d/0B9b6fB8CncnQbDBPeGh3UWZtQXM/edit?usp=sharing
Here is the link to the file named help_[sadface]2.vsd:
https://drive.google.com/file/d/0B9b6fB8CncnQanZneGpKYUtCVzg/edit?usp=sharing
I should note... probably the only thing I haven't done is consolidate the several dropmany and setformula loops that I have. Based on my current experience though... I don't see this saving me much more than 1-2 extra seconds at best.
I will give this a try tomorrow; hopefully I'm wrong and it speeds things up exponentially.
Hi Daihashi,
that's already pretty hardcore stuff. I'm impressed.
And the listed measures to speed up the code cover so mainly all what I've ever heard or read of. Nice job.
I couldn't get your code to run, so that I can't give any precise observation.
Just some thoughts however and for whatever they may help.
- If there's this significant speed difference between private and business configuration, it suggests that the speed problem is rather to be found in some I/O operations - either between files or applications/dlls. There shouldn't be that big difference in simple internal visio operations.
- Are there different office versions installed on private/business computers? I saw that you consider 32 and 64 bit systems.
- You may analyse systematically the duration of your routines. (http://stackoverflow.com/questions/198409/how-do-you-test-running-time-of-vba-code)
Regards,
I've just downloaded and tried this (Visio 2010/Windows 7 64 bit, Intel Core 2 Duo CPU E6850 @ 3GHz, 2GB memory), takes 1 second.
Had trouble with your string Replace of "in." as it is only "in" on my machine. You would be better using the ResultIU (internal units - which is always in inches) rather than ResultStr.
Quote from: AndyW on August 27, 2014, 10:35:23 AM
I've just downloaded and tried this (Visio 2010/Windows 7 64 bit, Intel Core 2 Duo CPU E6850 @ 3GHz, 2GB memory), takes 1 second.
Had trouble with your string Replace of "in." as it is only "in" on my machine. You would be better using the ResultIU (internal units - which is always in inches) rather than ResultStr.
thanks for the feedback on the replace string... and also trying it out.
I finally got some feedback from one of co-workers who I asked to test it. I placed several timers to cover each of the dropmany/setformula loops, and it seems that it might be isolated only to my laptop. This is both funny to me and frustrating. Funny because I've always suspected something was wrong with my corporate issued laptop, and frustrating for the exact same reason.
Hopefully my other co-workers will report that this works fine for them as well, and this post will actually end up being a non-issue.
Thanks again for the feedback!
I have seen corporate PCs perform very poorly with Visio where McAfee is used. Can you disable (or have it temporarily disabled) and see if that improves things.
Quote from: Yacine on August 27, 2014, 06:54:27 AM
Hi Daihashi,
that's already pretty hardcore stuff. I'm impressed.
And the listed measures to speed up the code cover so mainly all what I've ever heard or read of. Nice job.
I couldn't get your code to run, so that I can't give any precise observation.
Just some thoughts however and for whatever they may help.
- If there's this significant speed difference between private and business configuration, it suggests that the speed problem is rather to be found in some I/O operations - either between files or applications/dlls. There shouldn't be that big difference in simple internal visio operations.
- Are there different office versions installed on private/business computers? I saw that you consider 32 and 64 bit systems.
- You may analyse systematically the duration of your routines. (http://stackoverflow.com/questions/198409/how-do-you-test-running-time-of-vba-code)
Regards,
Thanks Yacine; a compliment from you means a great deal to me considering the large body of knowledge you have.
To answer some of your questions:
- It seems that the problem may simply be isolated to my computer. I placed several timers in the code and sent it to my co-workers; they don't experience the delay that I do. It's a relief that it's isolated to my computer.
- Unfortunately yes; I wish I could have included the full code, but the download would have been much larger. In my code, upon document open, it detects whether a person is using Office 2013, Office 2010, or 2007 and earlier, and it adjusts it's code accordingly. It also will detect between 64bit and 32 bit; the last part I wrote mostly for myself since I use 32bit at my job, and 64 bit on my home workstation. The code probably would have ran properly for you if I had left the "office detection" bits in the vss file. sorry about that :(
- Yes, I have actual timers in my test document. I stripped them out because I didn't want to annoy anyone here who was kind enough to test my code. The methods I used was GetTickCount, and I also used a more simplistic starttime=now and endtime=now method. This is how I was able to narrow down specifically where I was experiencing slowness; which now seems to be isolated to my PC only (pending further validations... if so then thank goodness, I've been beating my head against the wall to try to get this to go faster :)
>
[/list]
Thanks again Yacine; your compliment has really made my day since I still consider myself a novice. This just encourages me to work harder and learn even more. :)
Quote from: AndyW on August 27, 2014, 02:10:07 PM
I have seen corporate PCs perform very poorly with Visio where McAfee is used. Can you disable (or have it temporarily disabled) and see if that improves things.
Trust me, I wish I could but the system is "locked down". I can crack the local admin password on the computer, but then that breaks it's ability for the machine to join the domain. It seems that the domain somehow uses the local admin account to validate the machine certificate; although I'm not sure why they did it this way.
QuoteThanks again Yacine; your compliment has really made my day since I still consider myself a novice. This just encourages me to work harder and learn even more.
Hi Daihashi,
I honestly confess that I feel flattered, but not only is your compliment embarassing, but also not justified.
The fact that I post so often is only due to my addiction to visio, not my "knowledge" or "expertise".
Compared to the "first generation members", I actually do consider myself as novice too.
At some time I realised that all these champions are actually very speciallised and that if you are lucky enough to get a task that challenges you enough , you can master a certain domain visio (devotion required).
There are these fabolous guys here, like Paul as specialist in addons written in Pascal and trouble shooting of all kind, Wapperdude with its deep shapesheet knowledge, June with his Geometry magic, Al Edlund with his Databases and Racks, the big coding slavic fraction with Nikolay, Surrogate, and much more. Even some book authors like Chris (the Visio Guy), or John Goldsmith. But all of them are specialised in a certain area of Visio.
I wish you good luck in your "visio career". I think you found already your specialisation. ;)
Well.. I won't argue with you; I'll simply state that in comparison to you (and of course others), I am a novice. Also, it's almost not fair to try to compare yourself to the people you mentioned. I hope to one day be as good as some of them, but their skill is so far from my current abilities that they seem almost god like.
I gain quite a bit from your posts; I read many of them even though I don't participate in most threads. Your posts seem to always help me look at my own challenges in a different way, and allow me to see solutions that I originally did not realize upon first encountering them. Either way, I'm very appreciative to be on a forum like this... where I have access people like yourself, and others, who are so willing to help and share the knowledge that they have.
I am very glad that I found out about this forum. It is an amazing place. :)
I experienced Visio slow down in operations with the page when default printer was not available. It was attached to the computer that was turned off.
Maybe you have a similar reason.
Quote from: Croc on August 28, 2014, 06:20:27 PM
I experienced Visio slow down in operations with the page when default printer was not available. It was attached to the computer that was turned off.
Maybe you have a similar reason.
I'll load one of my older versions and try setting the default printer; although that seems a bit odd, but worth a shot.
Today another one of my co-workers experienced the same slowness that I did. So I decided to just make this a prebuilt shape; which obviously makes it very fast. If the default printer idea that Croc posted works then I'll go back to my previous method; if it does not then I will stick with the prebuilt shape for now. I wish I had more time to resolve this programmatically, but I've used up too much time on this one problem, and I'm already past due for this quarter's template release. :(
update: one thing that is interesting to note. The individual who experienced no slowness was using visio 2010, and the person who had the same results as me was using visio 2013 (which I am also using). I wonder if visio 2010 was more efficient with this code for some reason.
Oh, I forgot to mention. If anyone is curious and wants to know what the depth of automation my real template has, take a look at the documentsheet, pagesheet, and any hidden pages (UIvisibility=1) pagesheets that might be there. Some of the stuff you'll see is brute force, but I think I might have a few clever things in there that might be useful to some people. You can also look at the shapesheet formulas. I use the various sheets very heavily.
This document excerpt that I posted here is what I jokingly refer to as a "Network engineer in a box", because it can generate a number of solutions very easily, and automate most aspects of the documentation with minimal (to almost no) input required from the user. It bases the solutions around current approved standards, however since I keep all the code in the stencil file.. I have control of keeping all documents accurate. Upon document open the template makes a call to my server to see if there is an update available, if so it downloads the new stencil file. It will also make a call to the server if it sees the file doesn't exist.
The server backend is utilized very heavily, and actually allows documents to be aware of data in other documents... and alert the user about it immediately. So not only does it automate much of the documentation, but it also error/conflict checks across all other documents that use this template.
There's much much more to this, but I don't want to sound as if I'm bragging. I simply get very excited when I think of how I can help everyone around me through the power of automation, and then we can refocus that time that is saved on innovating new solutions. Visio is pretty awesome. :)
So I've done further testing, and while dropmany appears to make things faster in both Visio 2010 and Visio 2013... it seems that SetFormulas improves performance for Visio 2010 but not for Visio 2013.
Has anyone else noticed this with Visio 2013? It's pretty frustrating to spend 2-3 hours rewriting a section of code only to find out that there is no performance improvement when there should be.
I should note that I am already using the following at the start of my routine, and re-enabling them at the end. So I doubt that this is related to screen updating or recalculations.
Application.ScreenUpdating = False
Application.DeferRecalc = True
Application.LiveDynamics = False
Application.AutoLayout = False
Application.UndoEnabled = False
update to others who are also looking to improve their code execution time:
For the initial shape that I posted about, I went ahead and just pre-built the shape. The execution time was just far too long for me to try to improve upon.
For the shape that I posted about yesterday; which is a pair of switches that is made up of 16-17 different shapes, I've managed to improve the execution time here quite a bit.
First I took the 3 seperate "dropmany" and "setformula" sections in the main subroutine and consolidated them into a single drop/set. I then further consolidated 3-4 more called functions into the same dropMany and setFormulas that I have in the main sub routine and it has improved performance by 50%. Yesterday when I ran the code it took ~4 seconds to complete (3 seconds if I removed the progress bar). Today the code executes in about 2.13 seconds (~1.56 with the progress bar disabled).
This is on my home workstation; I estimate that on the corporate laptop... which doesn't have an SSD drive, and is bogged down by Mcafee and a bunch of other stuff, that it will take a bit over 4 seconds to execute. This particular sub drops ~17 shapes, and sets 224 formulas (not including formulas for the pagesheet). Ideally I'd like to get this down to about 0.5 seconds of execution time, but I am probably asking too much of VBA considering how many formulas I'm setting.
I'll keep tweaking things as time permits, but this will have to do for now.
Another minor update:
It turns out I was wrong. SetFormulas is running blazing fast, and the slowdown is occuring with dropMany; which takes ~ 1.55-1.6 seconds. The other significant loss of time comes from calling other functions that do not utilize the setformulas method; which I will be fixing very soon.
I've managed to shave an additional .3 seconds off of the execution time from yesterday by simply merging a couple of If Then statements that were repetitive. I also stopped using string evaluations, and instead have opted to use either Len or Ascw when applicable. For example:
Previously I was using a statement like this... the value retrieved will either be "Available" or "Unavailable"; and I am only interested in values that return as "Available":
If pos = "Available" then
I changed it to the following; which saved some time:
If Len(pos) = 9 then
Similarly; I got rid of as many Trim, Replace, and Left functions as possible and instead replaced them with AscW. In all these cases, the 1st character unicode value is enough to continue with the logic in my code. I also created some variables that would retrieve certain results once, and then used the variable throughout the sub when needed:
Previously:
If Replace(ActivePage.PageSheet.cells("PageWidth").ResultStr(""), " in.", "") = 8.5 Then
Changed to:
Dim pwidth As integer
pwidth = AscW(ActivePage.PageSheet.Cells("PageWidth").ResultStr(""))
If pwidth = 56 Then
In areas where conditional string evaluation was necessary, I replaced certain functions such as Replace,Trim,Left, etc. with Replace$,Trim$ and Left$. This also gave some improvement.
The execution time has been reduced from 2.13 seconds (yesterday's results), to 1.84 seconds. Once I finish figuring out the most efficient method then I will post up a list of Do's and Don'ts for code efficiency. I hope I can get this reduced even further without having to result to reduce the number of unique shapes/increase the number of geometry sections. Unfortunately I need these to remain seperate for text/formatting purposes.
wow... I further improved the execution time by another 0.1 seconds by simply moving the section of code for my progress bar up by 3 lines; very interesting.
I received further input from an additional 6 co-workers today. Coincidentally 3 of them were using Visio 2010, and another 3 were using Visio 2013... and the people with Visio 2010 experienced very fast build times for the shape that was taking 19-20 seconds to build. The people with Visio 2013 experienced the same slowness that I originally posted about.
So it seems that Visio 2010 is actually must faster than Visio 2013 when it comes to using DropMany and SetFormulas.
I already resolved this issue a few days ago by simply creating a pre-built master, and dropping that onto the page instead.... but I found it very interesting that Visio 2010 is much better than Visio 2013 when it comes to handling DropMany/SetFormulas.
I've gone ahead and reported this to Microsoft. The slowness, for anyone making heavy use of dropmany, is simply unbearable. There are lots of valid reasons and use cases to use drop many; I know I can simply resolve this by creating pre-built masters... but the fact that I do not have this problem with Visio 2010, and that I can replicate this on other computers using Visio2010 and Visio 2013, indicates to me that this is a problem that Microsoft really needs to address.
Hopefully they will take my comment seriously, and not take nearly 2 years to release a hotfix... like what they did for a different issue on Microsoft's forums.
it seems that the delay in visio 2013 is coming before the Enter Scope 1869 event fires. So the slowness seems to be just a moment before DropMany even starts. I tried catching the enterscope event and executing a doevents, but this doesn't help since it seems to be the moment my code hits the following line.. but somehow still before it even begins doing the dropmany:
intprocessed = ActiveWindow.Page.DropMany(cells1, xyarray, IDarray)
how could I go about making this line executing an event, so that I can catch the event upon hitting that line and try executing a doevents there?
wow.. out of curiousity, I tried to see if just performing a regular drop per shape would be any better. It wasn't faster, but to my amazement it is the exact same amount of time as using dropMany. Or I suppose more accurately, dropmany takes as long as simply using drop. hmmm
I figured it out; well, I only kind of figured out the problem.
I created a new document to do some further testing in a "clean" visio file. I then started moving some of the sub routines I wanted to test into it, and also started moving the necessary master files. When I went to move the master files it gives me an error# 318.
Error 318 seems to indicate that the master is trying to reference some documentsheet cells in the user defined cell section. I turned on event monitor to capture the events that were triggered upon trying to drop one of these masters, and it is indeed trying to reference a cell that is in my original documents documentsheet. What is bizarre however is that I searched in every shapesheet cell of the master, and there is not a single reference to those documentsheet cells.
In anycase; I decided to go ahead and generate the user-cells that it was complaining about, and it then would let me add the masters. I then ran my sub-routine; which normally takes between 2-8 seconds, and it only took 0.15 seconds.
So the problem seems to be with the original document. I'm not entirely sure what is corrupt about it, but something inside the original document is causing dropmany to perform very slowly. What is frustrating is that the problem does not exist with visio 2010. I suspect that the reason why 2010 performs well is because I originally created the document in Visio 2010. I just wish I knew what specifically was different so I don't have to recreate my original document.
I narrowed it down even further. It seems to be related to the large amount of shapedata that I have in the documentsheet. I've been able to reduce this dramatically by only having a handful of cells to place my format data in, and then have the remaining format cells reference those. Again, visio 2010 has no issue with the same amount of data... so it's peculiar that Visio 2013 has problems with it.
Prior to doing this the drop time on my home workstation was 2 seconds (~7-8 seconds on my corporate laptop), without a shape data section in the documentsheet the drop time is .15 seconds, and the drop time with the optimized document sheet is now .45 seconds.
I was able to test the "fresh" document on my corporate laptop today, and the total execution time is 2.10 - 2.17 seconds. This is significantly better, although I would still like to get it closer to about 1 second total time.
I wonder why Visio 2013 struggles, while Visio 2010 has no issue handling the same amount of information in the document sheet without the need for me to modify or optimize anything.
It's obvious, V2013 is an upgrade and an improvement over V2010. :o
Wapperdude
Firm believer that V2007 was the best version.
I've never experienced Visio 2007, but I have no doubt that you are probably right. The most frustrating part of making these heavily automated templates are the users; or the corporate images available.. depending on how you look at it.
Some people refuse to move off of Visio 2007 (understandably), others refuse to get off of 2010, and others still have decided to upgrade to 2013. To make matters worse the 2013 users can be either 32 bit or 64bit. So my templates have to account for all these variations.
I'm not fond of corporate application control through the use of SMS pushes, but this is one case where I wish it was being done. Coding for 1 version of Visio would make this much easier.
In any case, I'm just glad I was able to deduce where the problem was occurring. I'll make another post in a few days that is written more like an article; outlining all the optimizations I discovered that were useful for Visio 2013, as well as the things that Visio 2013 doesn't seem to handle well... and workaround suggestions.
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
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 ;D. 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.
Nice explanation. Reminds me why I never went into IT related stuff. Obviously, I had an oversimplified and incomplete vision.
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.
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.
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
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