Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: When should I use a dispatch table?

by traveler (Parson)
on Nov 30, 2006 at 23:37 UTC ( [id://587080]=note: print w/replies, xml ) Need Help??


in reply to When should I use a dispatch table?

I was pretty surprised by this, too. I have comments on your test, and then a theory. First the comments:

The values in @find are integers, but in the if_else comparison tree, you test for string equality.

Testing the hash for existance of a key first, seems wasteful. It might be faster if you did an eval and only acted on failure in that case. Of course, I haven't benched that, yet.

My theory: maybe, just maybe, perl does the thing C used to (and maybe still does) and and builds if-else chains into a hash table for evaluation. Dunno.

--traveler

  • Comment on 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
      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

        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). :-)

      runrig++, very clever. I had to stare at it for a second to realize what was going on.

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

      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.

        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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://587080]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (6)
As of 2024-04-19 18:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found