Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Feb 02, 2010

Efficiency of String Comparison

Which statement is more efficent in terms of processing?

[HTTP::uri] equals "/"

or

[HTTP::uri] == "/"

According to my interpretation of the official TCL doc, "equals" assumes the right side is already a string. On the other hand, "==" seems to assume the right side is a number. From the "==" description...

(i.e., numeric comparison if possible, exact string comparison otherwise).

So my conclusion is that "equals" is more efficent because the TCL engine does not have that extra decision to make.

I am just looking for a sanity check. I realize this is pretty meaningless in the context of a single rule, but we have this problem in many iRules - I'm looking for places to optimize. Thanks for your input.

4 Replies

  • I'd agree--it's more efficient to use eq for string comparisons as TCL doesn't have to try to convert the value from a numeric to a string. You could confirm this using a loop of x comparisons using eq versus == using timing (Click here).

     

     

    Aaron
  • Dude, you're fast. And if you confirm, then it's gold. Thanks for taking the time to give your thoughts.
  • Not sure what's going on here - it seems that the stats only update when I update the iRule, not when I hit the applied VIP. I'm running 9.3.1, and I don't have time to dig into it at the moment - maybe there is some obvious incompatibility.

     

     

    Regardless, here are the stats I got when I updated the iRule - not sure I trust them, though they do not seems to fit the theory:

     

     

    (==)

     

    RULE prigge_process_test

     

    +-> RULE_INIT 1 total 1 fail 0 abort

     

    | Cycles (min, avg, max) = (185842, 185842, 185842)

     

     

    (equals)

     

    RULE prigge_process_test

     

    +-> RULE_INIT 1 total 1 fail 0 abort

     

    | Cycles (min, avg, max) = (188005, 188005, 188005)

     

  • Using time (Click here) in tclsh, it looks like eq is more efficient when the two operands aren't equal. Maybe == can do two checks: the first as numeric and the second as strings if the first check doesn't match. Just a guess...

     

     

    eq versus == is the same when the operands are identical strings

     

    % time {expr {"a" eq "a"}} 1000000

     

    1 microseconds per iteration

     

    % time {expr {"a" == "a"}} 1000000

     

    1 microseconds per iteration

     

     

    eq versus == is shows eq is more efficient when the operands are not the same

     

    % time {expr {"a" eq "b"}} 1000000

     

    1 microseconds per iteration

     

    % time {expr {"a" == "b"}} 1000000

     

    2 microseconds per iteration

     

     

    I'll try testing this in an iRule at some point as well.

     

     

    Aaron