What is the time penalty for calling a macro?

[mfseeker]

A short piece of code can be saved either as a snippet or as a macro. If my macro uses that piece of code in several places, am I better off calling it as a macro or inserting it from a snippet? If I insert the code from a snippet, I can give users one macro rather than two. If I call the code as a macro, does it take significantly longer than the inline code?

[Cory]

In the beta testing I found that the Macro Run had a time penalty but it was minimal. The only reason I noticed it was because I had a macro that looped thru tens of thousands if items and called several macros each time. In this case it was too slow and i embedded the code. It improved some but not as much as I thought it would. In this case the real culprit was expanding variables. In this case I had an output accumulator and it would grow up to 10MB and MEP would have to keep resizing the var which slowed things down a lot. I wrote a simple macro at the time that would do some simple variable operations and test the macro run speed but I heard that some improvement had been made to the Macro Run and it's supposedly faster. My advice to you is to take 5 minutes to write a simple macro that repeats a variable number of times that has some simple variable operations. If you're clever you can create a start time and stop time with the new time variables and do some math to tell you how long it's taking per loop. As soon as you get it up to the point where you have a reliably measurable amount of time, say 10 seconds, Move half of the variable operations in your macro into another macro and call it using Macro Run and do th time test again.

 

My advice to you is to only put code in Macro Run if this code can be used by other macros frequently. IMHO the only reason for having it as a sort of quasi-subroutine. This way you can edit code in one place instead of several. This is a great advantage so I wouldn't throw it away unless there was a sizable time penalty.

 

If your interested I did do some dyno runs with MEP on many different things like speed of repeat with folder, file writes and reads, and other such commands to see how long they took. It was very telling and helpful when considering how to design large macros. I can dig them up if you're interested.

[terrypin]

If your interested I did do some dyno runs with MEP on many different things like speed of repeat with folder, file writes and reads, and other such commands to see how long they took.

 

Cory: What are 'dyno runs' please?

 

--

Terry, East Grinstead, UK

[Cory]

Sorry, you're probably not a Gear Head... or, what is it you call them over there? Oh yeah, Petrol Heads. A dynamometer is a device for measuring power most commonly known for measuring horsepower on car engines. You make a mod, stick the engine on a dyno and do a 'dyno run' to see how much more power you make. I create macros that are analogous to a dyno to test macro performance. In this case I would create a simple macro that does some variable operations a few hundred thousand times (using repeat). In the baseline test I would do it without Macro Run. Then I would do the same operations again with macro runs where I moved the variable operations to the called macro. IOW we're doing the same thing. Take the time delta and divide by the number of iterations and now I have a crude quantification of how much time is added by doing something with Macro Runs. Of course many factors affect this and it's not terribly scientific but it gives one a fairly good idea. I identified a few different performance issues in MEP during beta this way. And FWIW they only take a few minutes to write.

[terrypin]

Sorry, you're probably not a Gear Head... or, what is it you call them over there? Oh yeah, Petrol Heads. A dynamometer is a device for measuring power most commonly known for measuring horsepower on car engines. You make a mod, stick the engine on a dyno and do a 'dyno run' to see how much more power you make. I create macros that are analogous to a dyno to test macro performance. In this case I would create a simple macro that does some variable operations a few hundred thousand times (using repeat). In the baseline test I would do it without Macro Run. Then I would do the same operations again with macro runs where I moved the variable operations to the called macro. IOW we're doing the same thing. Take the time delta and divide by the number of iterations and now I have a crude quantification of how much time is added by doing something with Macro Runs. Of course many factors affect this and it's not terribly scientific but it gives one a fairly good idea. I identified a few different performance issues in MEP during beta this way. And FWIW they only take a few minutes to write.

 

Thanks, understood.

 

--

Terry, East Grinstead, UK

[mfseeker]

If your interested I did do some dyno runs with MEP on many different things like speed of repeat with folder, file writes and reads, and other such commands to see how long they took. It was very telling and helpful when considering how to design large macros. I can dig them up if you're interested.

 

That would be great, Cory. So far I haven't graduated to designing large macros, but even in smaller macros there are occasions where we are working in loops with many reps such that timing info becomes important.