Tcl, return values and efficiency.
October 13, 2006 9:16 AM Subscribe
TclFilter: Assuming $var is already set, is there any performance/efficiency difference if a Tcl proc calls "return $var" versus just plain "return"
I have a Tcl procedure that accepts an array name as an argument and adds some new values to the array. In the process of doing this, it sets a variable that I currently have no need for outside the scope of the proc. But I can see possible future instances where it might be useful to get the value of the variable back. So, while the proc currently returns nothing, I am considering returning the value of the variable for some day use. What the hell, right?
This proc is relatively low-level, however, and will be called in loops of thousands of iterations. Will returning the value somehow use more memory if the caller (for now) just ignores what is returned? Are there other ways changing the return value may slow things down? Are there any (Tcl-specific or not) 'best practices' conventions in play here?
I have a Tcl procedure that accepts an array name as an argument and adds some new values to the array. In the process of doing this, it sets a variable that I currently have no need for outside the scope of the proc. But I can see possible future instances where it might be useful to get the value of the variable back. So, while the proc currently returns nothing, I am considering returning the value of the variable for some day use. What the hell, right?
This proc is relatively low-level, however, and will be called in loops of thousands of iterations. Will returning the value somehow use more memory if the caller (for now) just ignores what is returned? Are there other ways changing the return value may slow things down? Are there any (Tcl-specific or not) 'best practices' conventions in play here?
The 'best practice' is to avoid all use of tcl whenever you care even the slightest bit about performance.
That said, in this case tcl should* have little relative performance impact, because all you're doing is putting a value on the stack before returning to the enclosing scope, which ought to be minimal in impact.
The best way to handle questions like this is to write a program which does the operation each way a few hundred thousand times and times the result. If one way is significantly better you'll notice.
posted by felix at 9:55 AM on October 13, 2006
That said, in this case tcl should* have little relative performance impact, because all you're doing is putting a value on the stack before returning to the enclosing scope, which ought to be minimal in impact.
The best way to handle questions like this is to write a program which does the operation each way a few hundred thousand times and times the result. If one way is significantly better you'll notice.
posted by felix at 9:55 AM on October 13, 2006
Response by poster: You guys are right about the profiling, of course. Thanks.
Just using the unix 'time' command, there seems to be a difference of about a 1/10 second (in the 'user' line), calling the proc 10,000 times. Neglible for my needs, but apparently something. I guess I'll leave it as is.
(Not using Tcl isn't an option, and our coding standards require every proc to call return. The data structure could be tweaked, but the "upvar array" thing is kinda the standard idiom in the existing codebase.)
posted by If I Had An Anus at 10:13 AM on October 13, 2006
Just using the unix 'time' command, there seems to be a difference of about a 1/10 second (in the 'user' line), calling the proc 10,000 times. Neglible for my needs, but apparently something. I guess I'll leave it as is.
(Not using Tcl isn't an option, and our coding standards require every proc to call return. The data structure could be tweaked, but the "upvar array" thing is kinda the standard idiom in the existing codebase.)
posted by If I Had An Anus at 10:13 AM on October 13, 2006
If I Had An Anus writes "Just using the unix 'time' command..."
Don't profile that way; call the two variant routines from within the same program (and if you can, on dedicated or visualized hardware); that way you're not counting Tcl's own set-up time, which likely is both expensive (memory allocation, mostly) and somewhat time dependent on the OS (again, memory allocation, mostly).
"...calling the proc 10,000 times."
With a modern processor, call each variant at least one million times.
(When I profile stuff on a significantly slower ipod, I use loops of at least 100000 iterations, and a microsecond hardware timer; admittedly, that's profiling C code.)
posted by orthogonality at 10:22 AM on October 13, 2006
Don't profile that way; call the two variant routines from within the same program (and if you can, on dedicated or visualized hardware); that way you're not counting Tcl's own set-up time, which likely is both expensive (memory allocation, mostly) and somewhat time dependent on the OS (again, memory allocation, mostly).
"...calling the proc 10,000 times."
With a modern processor, call each variant at least one million times.
(When I profile stuff on a significantly slower ipod, I use loops of at least 100000 iterations, and a microsecond hardware timer; admittedly, that's profiling C code.)
posted by orthogonality at 10:22 AM on October 13, 2006
Response by poster: Sorry, I meant I have a script that calls the proc (10,000) times and I ran the time command on that script.
(You're writing C to be run in ipods? Fun.)
posted by If I Had An Anus at 10:32 AM on October 13, 2006
(You're writing C to be run in ipods? Fun.)
posted by If I Had An Anus at 10:32 AM on October 13, 2006
I just ran a quick little test script that calls two procs, one with a plain return and one with a return value, each a million times. I just use [clock seconds] to track time so the granularity is not very small but I don't see any difference at all in the speed of either proc when running with TCL8.3 on both Fedora and FreeBSD.
posted by octothorpe at 12:29 PM on October 13, 2006
posted by octothorpe at 12:29 PM on October 13, 2006
Oh and my sympathies to you from someone who writes TCL code pretty much full time.
posted by octothorpe at 12:48 PM on October 13, 2006
posted by octothorpe at 12:48 PM on October 13, 2006
Response by poster: Heh, thanks octothorpe. I actually kind of like Tcl.
posted by If I Had An Anus at 8:33 PM on October 14, 2006
posted by If I Had An Anus at 8:33 PM on October 14, 2006
This thread is closed to new comments.
But if your need for speed is really this great, consider that the real overhead likely lies in your use of Tcl arrays and particularly in adding to them; using a different data structure may yield much greater speed/efficiency improvements. If your need for speed isn't great enough to justify using a different data structure (or native C code), the difference between returning nothing and returning a var is too negligible to worry about.
Since Tcl is interpreted you're almost certainly paying the cost to return something regardless (i.e., the interpreter is traversing a node tree, calling (in C code) an eval function recursively, and eval is returning something that (in C) can be or can point to any Tcl type. So the extra overhead is traversing an assignment node and its two operand nodes, which is probably a simple shallow copy pointer assignment in C.
But finally, profile both versions. That takes less time than it took me to write this.
posted by orthogonality at 9:42 AM on October 13, 2006