Forum Discussion
smp_86112
Cirrostratus
CirrostratusEfficiency 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
hoolioI'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
smp_86112Dude, you're fast. And if you confirm, then it's gold. Thanks for taking the time to give your thoughts.- smp_86112Not 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) - hoolioUsing 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
