New Developments with eVSM

I just realized I've been working on eVSM for almost a year, and haven't really talked about any of the changes we've made in that time.  Part of the reason for that is I've not wanted to talk about new upcoming features until they were released and well documented.

I now realize many features have been in use for at least three months, if not longer.

The first I'd like to talk about is one of the flagship functions of eVSM, the eVSM Calculator.  This tool has been around since early versions of eVSM, and has grown new features over the whole time of its existence.  What used to be a simple function for exporting shape data fields to Excel and pulling user equations back in from Excel has grown into a powerful tool that writes the equations for you.

The complexity of the code behind the calculator grew quite a lot, since the original base code was never really designed to handle some of the functionality it grew to support.  This ultimately ended up in long run times for calculating a map.  While probably good for the coffee, water bubbler, and gossip industries, we realized the calculator was getting too slow.

So we rewrote the tool from scratch.  Which is usually a bad idea.  But in our case, we sort of treated the old calculator as a 10 year old prototype that happened to work wonderfully in production.

The old calculator used VBA collections to hold a lot of the data from the map in memory, which made things really hard to debug.  I did modify the collection code to also store the keys for the collection within the collection, so I could at least see what data was where.  But in the end I ended up designing a simple object model using VBA Classes, which provides us an "early binding" of many of the properties we want to know about our eVSM shapes (tag ID, paths present, variables present).

The overall hierarchy we have now is a Map class at the top level, which holds all the data for a single Visio page.  Each map has a list of all the "Row" centers, which are individual process (or other type) blocks, which we store as a Tag object.  The Tag object keeps a pointer to the center shape, the tag shape, and holds a list of Paths and Data.  The Data collection is a list of NVU objects.

By putting all the page data into this object model, we found we could read the Visio page one time, and keep all the data we wanted in memory, in very convenient and (relatively) efficient objects.  The other big performance gain came from using batch array techniques to talk to the Excel application object as few times as possible.  We found we could make our VBA code as inefficient as we wanted, as long as we minimized the number of calls to Excel and Visio's application objects.

Overall we found we were getting at least 5x speed improvements, while maintaining the functionality of the tool.  We did have to find and fix many bugs, most of which were probably encountered the first time writing the old calculator.  But I'm happy we ended up rewriting from scratch, as this new object model has enabled us to do some great things, which I'll have to put in other posts.