hexagon logo

Why is writing to PC-DMIS from VBA so slow?

I have two scripts that do very similar things : Read scan point data from PC-DMIS and then write scan point data back into PC-DMIS. One version of the script is written and executed in PC-DMIS basic. The other is written in Excel VBA and is executed through Excel by calling the macro from a very simple PC-DMIS script.

The PC-DMIS only version writes the scan data out to a temp file and then reads it back out of the file and writes to PC-DMIS. The excel version reads the data out into memory in a 2D array and then writes it back into PC-DMIS from the array, no external files involved.

I figured the Excel version would be faster since everything is in memory. It turns out that it is wicked slow and takes about 11 seconds to write a 64 point scan while the PC-DMIS version does it in less than 1 second. All the time is in the writing via the Puttext method. Reading from PC-DMIS into the array takes a fraction of a second but writing it back out into PC-DMIS takes 11 seconds. In the PC-DMIS only version both operations take a fraction of a second.

Is VBA just inherently slow for this kind of thing? Anyone else experienced this?
Parents
  • Using generic objects and variants creates some additional overhead while determining what type of object or datatype is being dealt with.


    I tested the speed difference caused by specifying objects as PCDLRN types instead of as generic "Object". There was no significant difference in speed even on a very long filtering routine that processes 10's of thousands of points. I agree that it is best practice to do this but it doesn't really improve execution speed in a significant way.

    Command.FeatCmd.SetHit could combine 3 separate Command.PutText calls into one.


    This one has a huge effect. Switching from .puttext to .sethit reduced run time by ~83%! I went from an average of 247 seconds down to 41 seconds.
Reply
  • Using generic objects and variants creates some additional overhead while determining what type of object or datatype is being dealt with.


    I tested the speed difference caused by specifying objects as PCDLRN types instead of as generic "Object". There was no significant difference in speed even on a very long filtering routine that processes 10's of thousands of points. I agree that it is best practice to do this but it doesn't really improve execution speed in a significant way.

    Command.FeatCmd.SetHit could combine 3 separate Command.PutText calls into one.


    This one has a huge effect. Switching from .puttext to .sethit reduced run time by ~83%! I went from an average of 247 seconds down to 41 seconds.
Children
No Data