RE: Functions prototypes and real #defines

[Quinn Tyler Jackson <quinn-j@...>]

> Eh, are you guys serious? The dispatching through a table is
> definitely a lot faster than the if-elseif-end approach on a
> simple 6-option benchmark I'm running here...

Er, yes I am serious. ;-)

function traverse(N)
   local s = N:GetRuleName();
   local r = 0.0;

   if (s == "expr_seq") then
       r = expr_seq(N);
   elseif (s == "expr") then
       r = expr(N:GetChild(0));
   elseif (s == "expr_add") then
       r = expr_add(N);
   elseif (s == "expr_mult") then
       r = expr_mult(N);
   elseif (s == "expr_pow") then
       r = expr_pow(N);
   elseif (s == "expr_integer")	then
	   r = expr_integer(N);
   elseif (s == "expr_variable") then
       r = expr_variable(N);
   elseif (s == "expr_bind") then
       r = expr_bind(N);
   end

   return r;
end

Given the parser input:

    {a:1},{b:10},1*a+b*5^a/2*3+(15/(b*2)+5)+1*a+b*5+a/2*3+(15/(b*2)+5);
    {a:2},{b:11},1*a+b*5^a/2*3+(15/(b*2)+5)+1*a+b*5+a/2*3+(15/(b*2)+5);

Which traverses nodes in a distributed fashion, takes exactly (on my system)
the same amount of time as the dispatch table version of the above that does
this:

    traversal_table = { expr_seq = function(N) ... end, expr = function(N)
... end, etc. };

    function traverse(N)
        return traversal_table[N:GetRuleName()](N);
    end

As you can see from the parser input, the distribution of expression types
covers all of them.

I suspect that I got no gain in performance by using a dispatch table
because of the function I chose to optimize: it's not a bottleneck to begin
with, so overall parser/evaluation time is not influenced enough. When I
made the traversal table local, however, the hit was noticeable. Had I used
the dispatch table optimization in a bottleneck, I may have seen performance
gains.

--
Quinn