LoveNoodles
Altocumulus
Altocumulusequals vs eq?
Hi, is there any documentation or articles out there that suggest using "equals" is more efficient than using "eq" in string comparisons in irules?
Forum Discussion
3 Replies
Dave_McCauley_3Cirrostratus
You could run a test with two irules using each and checking the timing in the "tmsh show ltm rule" command. Hit each irule with apache bench 100k times and see what the timing looks like.
I would venture a guess that since they're both string comparison operators, they probably use the same code under the hood. "==" should be less efficient for strings since it has to deal with integers as well. Unless the iRule devs found some giant inefficiency within the TCL eq operator (Unlikely), it's probably just to make a more readable iRule.
jaikumar_f5MVP
As said by Dave, it is also my understanding that equal and eq are same. They are string operator. The comparison should be eq with ==. As == is a numeric operator. So when you compare using "eq" or "equal", there will be less cycle time, as it would treat both values as strings. But if compare using "=", there will be higher cycle time, as tcl would convert each string to integer.
- Lee_Sutcliffe
Nacreous
It's worth noting that 'equals' is an iRule extension to TCL, whereas 'eq' is native TCL. Most iRule extensions such as 'starts_with' 'contains' 'not' etc have been added to make code easier to read.
Details of iRule operator expressions can be found in the Wiki https://devcentral.f5.com/wiki/iRules.Operators.ashx
Jason Rahm wrote an article a couple of months ago: Choose Your Operator Wisely
In it he compares 'starts_with' (iRule extension) and string match (native TCL). The native TCL command resulted in a 4.6% CPU saving.
I would probably always lean towards native TCL commands being quicker as anything else has been added on top - That said, like other answers have suggested, using the timing feature may help gauge a more accurate answer.