为什么 listFindNoCase() 和 listFind() “快得多”？比 CF 中的简单 OR / IS 更好吗？
我无法理解，为什么使用 listFindNoCase() 和 ListFind() 是进行一系列 OR 和 IS/EQ 比较的首选方法？ JVM 是否能够对其进行优化并生成高效的代码，而不是进行必须处理字符串标记化的函数调用？还是CF做了一些效率低得多的事情？
使用
listFindNoCase()或listFind()代替 is 和 or 运算符 将一项与多项进行比较。他们的速度要快得多。
http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html
I fail to understand, why is using listFindNoCase() and ListFind() the preferred way of doing a series of OR and IS/EQ comparison? Wouldn't the JVM be able to optimize it and produce efficient code, rather then making a function call that has to deal with tokenizing a string? Or is CF doing something much more inefficient??
Use
listFindNoCase()orlistFind()instead of the is and or operators
to compare one item to multiple items. They are much faster.
http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
答案很简单：类型转换。您可以比较 2 个 EQ“2”或 now() EQ“2011-01-01”或真正的 EQ“YES”。转换（多种类型）和比较的成本相当高。
ListFind()不需要尝试多次转换，因此速度要快得多。
这就是动态类型的代价。
The answer is simple: Type conversion. You can can compare a 2 EQ "2" or now() EQ "2011-01-01", or true EQ "YES". The cost of converting (to multiple types ) and comparing is quite high.
ListFind() does not need to try multiple conversions, so it is much faster.
This is the price of dynamic typing.
我也觉得这很奇怪。我唯一能想到的是，列表元素被添加到一个快速集合中，该集合根据元素包含的一些令人敬畏的散列来检查元素是否存在。事实上，对于大型或非常大的列表来说，这会更快。较小的列表应该显示很少或没有速度提升。
I find this odd too. The only thing I can think of is that the list elements are added to a fast collection that check if an element exists based on some awesome hash of the elements it contains. This would in fact be faster for large or very large lists. The smaller lists should show little or no speed boost.