On Nov 13, 2005, at 1:22 AM, Sherm Pendley wrote:
On Nov 12, 2005, at 11:18 PM, Ken Williams wrote:
Yeah, I know, but I posted it because I didn't really like the other
solutions; while they use "better" (and more complicated) techniques,
they won't actually solve the OP's problem. The "pretend you have
methods instead of subroutines" solution is just wishful thinking,
and the "dispatch tables" solution seems overengineered and won't
work unless the specific list of allowed functions (rather than just
a naming-scheme pattern or similar) is known to the dispatcher.
The subroutines have to be known anyway. Unless, of course, you're
going to let the eval() just crash...
They have to *exist*, but they don't have to be known to the dispatcher.
When in doubt, benchmark it:
[...]
Benchmark: timing 100000 iterations of Dispatch Table, Eval, Symref...
Dispatch Table: 17 wallclock secs (14.77 usr + 0.29 sys = 15.06 CPU)
@ 6640.11/s (n=100000)
Eval: 155 wallclock secs (139.45 usr + 3.23 sys = 142.68 CPU) @
700.87/s (n=100000)
Symref: 18 wallclock secs (17.49 usr + 0.35 sys = 17.84 CPU) @
5605.38/s (n=100000)
Yeah, that seems about right.
The Eval results are no surprise - it has to compile the string for
each iteration, which is a huge performance hit.
The symref approach has some overhead too, I suppose because of the
extra scoping block for "no strict", but it's relatively small. Still,
it's enough to make using symrefs a questionable idea.
Well, symrefs do start out as a questionable idea in the first place.
It's old-school programming reminiscent of "goto" and "poke". But it
seemed like exactly what James was looking for - he had the name of a
function in a variable and wanted to call it. So rather than treat
this as an x-y problem, I decided to just answer the question
straightforwardly.
-Ken
