> Reason I am asking is that it the expression will be used in a script that
> might be triggered thousands of times a day (if my site become popuplar)
Firstly, as Igal says, thousands of times a day is nothing for a modern system. All of the options will cope fine with that - you'll have plenty of other bottlenecks to worry about first.
Secondly, you've confirmed that this is premature optimisation. Whilst fast code is generally preferred, your focus should be on creating working maintainable code, (and not being distracted by issues such as this).
Once you have a completed application with a full set of tests and nothing better to do, then you can profile it to determine if this have any meaningful difference, and then make informed changes as required.
> Azadi Saryev mentioned the IS 0 to be reduntant. Is it?
Yes, if you remove the NOT at the start too.
0 is false, -1 and 1 are both true.
(It is perfectly valid to rely on the automatic conversion of integers to boolean.)
> Also, does it matter using EQ 0 or Is 0.
They are both aliases for the same operator, and thus produce the same bytecode.
Again, Railo is Open Source; you can look at the source and see this...
...both operators result in the same call: expr = decisionOpCreate(data,OPDecision.EQ,expr);
(FWIW, it looks like this operator then results in the same string comparison method as compareNoCase, but I'm not going to spend time looking in detail for the reasons given below.)
> Not Compare() EQ 0 faster than Compare() NEQ 0 :) (i think NEQ is
> the same as <> which means it has to test if it is smaller and greater than
> so that would be less fast?)
Again, this question is almost certainly just wasted brain power. Any difference between them is almost certainly completely insignificant and overshadowed by other areas of your code.
Use NOT compare(a,b)
if you're looking for equal strings and compare(a,b)
if you're looking for unequal strings.
If case isn't important, use EQ, NEQ, compareNoCase, or NOT compareNoCase, as preferred.
Any supposed performance issue doesn't exist until you've measured/profiled your application appropriately.
If you have
done appropriate speed/load tests then you have something to compare against and can do practical tests to get actual results, (and if you do discover anything interesting there it'd be great to know).
Without such testing you're just worrying over premature optimisation and it is better use of your time to trust in Micha squeezing the best performance out of Railo, so that you can concentrate on what your application is doing. :)