Why is listFindNoCase () and listFind () "much faster" and then just OR / IS in CF?

I don’t understand why uses listFindNoCase() and ListFind() preferred way to do a series of comparing OR and IS / EQ? Can't the JVM optimize it and create efficient code, and then make a function call that needs to deal with string tokenization? Or is CF doing something much more inefficient?

Use listFindNoCase() or ListFind() instead of the is and or statements to compare a single item with multiple items. They are much faster.

http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html

+4
source share
2 answers

The answer is simple: enter the conversion. You can compare 2 equalizers "2" or "now" () EQ "2011-01-01" or true EQ "YES". The cost of conversion (for several types) and comparison is quite high.

ListFind () does not need to try to perform several conversions, so it is much faster.

This is the price of dynamic input.

+11
source

I also find this strange. The only thing I can think of is that the list items are added to the speed dial, which checks if the item exists based on some terrible hash of the items it contains. This would be faster for large or very large lists. Smaller lists should show little or no speed up.

+1
source

All Articles