chromatic,
In private /msg with madbombX I made this very point. When benchmarking it is important to eliminate as many factors unrelated to what you are testing as possible. In my benchmark generating code however, no IO comes into play (that I can see anyway). This is strictly determining the difference between a series of equality tests (linear search) and a hash lookup, reference dereference, and nearly empty sub execution.

In mumble years of programming, I can't think of a single example where the overhead of a dispatch table versus cascading conditionals made a whit of difference compared to the cost of performing IO. Therefore, unless I ever write a FFT or a petabyte-Ethernet driver, I don't see much point to worrying about a handful of milliseconds of difference between two constructs where one is so much more maintainable than the other.

Then again, almost every program I've ever written performs some sort of IO somewhere.

As it's the holidays, can I wish that Benchmark refused to give meaningful results for syntax questions and only helped profile various algorithms?

chromatic already has the IO part handled but your comparison is also getting dwarfed by making those function calls. Remove those too, they're one of the more expensive things you can do in perl (except for IO and just deliberately sleeping).

diotalevi,
Remove what function calls? The ones that make the dispatch table a dispatch table and subsequently the exact thing I am benchmarking? While I value chromatic's opinion (and your's), there is no IO involved. He was making the point that it is silly to worry about a few microseconds here and there if your program was doing IO.

So what are you guys trying to say - it is pointless to Benchmark any program that does IO or has function calls? I specifically isolated the bench to the difference between an if/elsif chain and its equivalent dispatch table. I appreciate constructive critism but I am not seeing it here.