Re: When should I use a dispatch table?

Replies are listed 'Best First'.
Re^2: When should I use a dispatch table? by runrig (Abbot) on Dec 01, 2006 at 00:04 UTC
Avoiding exists: `($dispatch{$item} \|\| $dispatch{default})->()` [download]	[reply] [d/l]
Re^3: When should I use a dispatch table? by Limbic~Region (Chancellor) on Dec 01, 2006 at 00:28 UTC
runrig, The issue that traveler pointed out was that I tested if a key existed when I didn't need to. Only when the user defines the -u option is it necessary to test for the hash key's existance. Without the -u, there is no default condition and the exists can be avoided. I corrected the template accordingly. You have mentioned an alternative way of determining which sub to dispatch. Unfortunately it may actually be less efficient than exists. You are fetching the value and testing it for truth where exists need only check to see if the key is present in the hash. Cheers - L~R	[reply]
Re^4: When should I use a dispatch table? by runrig (Abbot) on Dec 01, 2006 at 07:21 UTC
Yes, my version requires that there is a default (I hadn't examined the full version of your code closely as to whether or not it required a default), and although I know exists is more efficient than fetching the value unconditionally, overall efficiency depends on what the common case is. If most of the time you are fetching an existing value, then you may as well fetch it instead of testing for existence and then fetching it anyway. Your version always tests for existence then fetches one value or the other. Also, I agree w/chromatic's rant below, and the usual rant about premature optimization also applies (though I realize benchmarking this sort of thing can sometimes be a fun way to pass the time). :-)	[reply]
Re^3: When should I use a dispatch table? by friedo (Prior) on Dec 01, 2006 at 00:26 UTC
runrig++, very clever. I had to stare at it for a second to realize what was going on.	[reply]
Re^2: When should I use a dispatch table? by Limbic~Region (Chancellor) on Nov 30, 2006 at 23:46 UTC
traveler, The values are integers only because it made enumerating easier. The string equality is intentional. The 1 .. n could have as easily been 'a' .. 'z'. The testing for the hash key existance is necessary sometimes (default condition). The template didn't discriminate and always added it. Thanks to your keen eye, it has been fixed. It did not change the results that much with or without default conditions. Cheers - L~R	[reply]
Re^3: When should I use a dispatch table? by traveler (Parson) on Nov 30, 2006 at 23:53 UTC
The values are integers only because it made enumerating easier. The string equality is intentional. The 1 .. n could have as easily been 'a' .. 'z'. OK. But doesn't that make the ifelse code slower because it has to stringify and/or do string comparison, while the hash can do an integer comparison? I did try another test. Since the values were integers I replaced the dispatch table hash with an array and performance improved, but not enough to catch the ifelse. I am still quite confused.	[reply]
Re^4: When should I use a dispatch table? by Limbic~Region (Chancellor) on Dec 01, 2006 at 00:18 UTC
traveler, Stringification happens both in the hash table and in the if/elsif equality test so it is fair. The eq forces string context and so do hash keys. Anyone that has tried to use a reference as a hash key can attest to that. Cheers - L~R	[reply]