许多旧的ColdFusion性能警告仍然适用于CFMX 8？ [英] Do many old ColdFusion Performance admonitions still apply in CFMX 8?

问题描述

我有一个旧的标准文档，已经经历了几次迭代，它的根源回到ColdFusion 5天。它包含一些警告，主要是为了性能，我不确定仍然有效。

I have an old standards document that has gone through several iterations and has its roots back in the ColdFusion 5 days. It contains a number of admonitions, primarily for performance, that I'm not so sure are still valid.

这些任何一个仍然适用于ColdFusion MX 8？

Do any of these still apply in ColdFusion MX 8? Do they really make that much difference in performance?

• 请使用 compare（） compareNoCase（）而不是在比较字符串时不是


• 使用 evaluate（），除非没有其他方式来编写代码


• 不要使用 iif ）


• 始终使用 struct.key 或 struct [key] code>而不是 structFind（struct，key）


• 不要使用 incrementValue

• Use compare() or compareNoCase() instead of is not when comparing strings
• Don't use evaluate() unless there is no other way to write your code
• Don't use iif()
• Always use struct.key or struct[key] instead of structFind(struct,key)
• Don't use incrementValue()

推荐答案

• Compare（） / CompareNoCase（） ：不区分大小写在Java中比较昂贵。
除非没有办法。 对这一个说得多。我不使用它，因为整个 DE（）附带的东西吸了这么多。

• code> struct.key over StructFind（struct，key） ：我怀疑内部都使用相同Java方法来获取结构项。 StructFind（）只是堆栈上的一个函数调用。我从来没有使用它，因为我不知道它会带来什么好处。我想这是为了向后兼容性。


• IncrementValue（） ：我从来没有使用一。我的意思是，它是16个字符，甚至不增加变量在原地。


• Compare()/CompareNoCase(): comparing case-insensitively is more expensive in Java, too. I'd say this still holds true.
• Don't use evaluate(): Absolutely - unless there's no way around it. Most of the time, there is.
• Don't use Iif(): I can't say much about this one. I don't use it anyway because the whole DE() stuff that comes with it sucks so much.
• struct.key over StructFind(struct,key): I'd suspect that internally both use the same Java method to get a struct item. StructFind() is just one more function call on the stack. I've never used it, since I have no idea what benefit it would bring. I guess it's around for backwards compatibility only.
• IncrementValue(): I've never used that one. I mean, it's 16 characters and does not even increment the variable in-place. Which would have been the only excuse for it's existence.

一些关注点落在过早优化角落，即IMHO。个人偏好或编码风格分开，我只会开始关心一些细节在一个沉重的内部循环，陷入了应用程序。

Some of the concerns fall in the "premature optimization" corner, IMHO. Personal preference or coding style apart, I would only start to care about some of the subtleties in a heavy inner loop that bogs down the app.

例如，如果您不需要不区分大小写的字符串比较，那么使用 CompareNoCase ）。但我会说99.9％的时间实际性能差异可以忽略不计。当然，你可以写一个循环，每次迭代10万次不同的操作，你会发现他们的表现不同。但在现实世界的情况下，这些学术差异很少产生任何可测量的影响。

For instance, if you do not need a case-insensitive string compare, it makes no sense using CompareNoCase(). But I'd say 99.9% of the time the actual performance difference is negligible. Sure you can write a loop that times 100000 iterations of different operations and you'd find they perform differently. But in real-world situations these academic differences rarely make any measurable impact.

这篇关于许多旧的ColdFusion性能警告仍然适用于CFMX 8？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！