Comments on: Define local macros in one place, use them everywhere

By: Michael P. Manti

Michael P. Manti — Sat, 27 Feb 2010 19:16:41 +0000

Thanks for the pointer to your previous post. Like you, I outline my do-files, and I do have master do-files that call other do-files in sequence. But I suspect that you take encapsulation farther than I do. If I recall correctly, you have clients that you provide regularly updated analyses, right? Whereas I often perform an analysis only once, but I want and need it to be reproducible by myself and others.

I adapted my workflow from J. Scott Long's The Workflow of Data Analysis Using Stata. (I'm still trying to get my colleagues to drink the Kool Aid.) Have you read it? I think you would find it interesting.

I'm curious about your profiler! Please do embed it in a future post. Thanks!

By: Gabi Huiber

Gabi Huiber — Sat, 27 Feb 2010 18:31:24 +0000

No, I hadn't profiled it, but I did now -- meaning, I wrote a do-file that ran both solutions 500, then 1000 times and checked run time. You're right that there's no noticeable performance gain in what I propose. I'm surprised. Thanks for bringing it up. About my use case: I seldom write ado-files. Instead, I write do-files, but my usual do-file is structured as a collection of separate programs that call each other as needed. It doesn't always start that way, but that's what it looks like in its final form. This way I can avoid repeating code and I can debug pieces of it individually, without worrying about stuff that already works. I explained the general structure here a while back. When I make do-files reference each other, it's always the case that a parent do-file runs a child do-file and the child has no explicit program calls (it's missing Section 4, Program execution). The child, in other words, just makes some additional program definitions available to the parent. If anybody's curious about my profiler, I put it all on snipt and I could embed it in a future post.

By: Michael P. Manti

Michael P. Manti — Sat, 27 Feb 2010 00:55:36 +0000

Maybe I don't understand your use case. If you run any other program that stores its results to return space, you've got to call -defineMyLocals- again because your locals have been clobbered. Doesn't this negate the performance advantage?

I suppose I structure my work differently. I usually write my programs as -ado- files that are passed information via -syntax-; I rarely write programs midstream in a -do- file. When necessary, I will pass information via judicious use of -global- a la the -ml- suite of programs. But, then, when I encapsulate code via -program-, it typically performs a well-defined task of general utility such as a statistical procedure or a data manipulation.

Also, I use -include- in my -do- files rather liberally, and I haven't noticed a significant performance hit. Have you profiled this? How much speed are you gaining?