许多旧的ColdFusion Performance告诫仍然适用于CFMX 8吗？

Question

我有一个旧的标准文档经历了几次迭代，并且在5天内回归ColdFusion。它包含许多告诫，主要是为了表现，我不太确定它仍然有效。

这些仍然适用于ColdFusion MX 8吗？他们真的在性能方面做出了很大的改变吗？

• 比较字符串
时，请使用compare()或compareNoCase()代替is not
• 除非没有其他方法可以编写代码，否则不要使用evaluate()
• 请勿使用iif()
• 始终使用struct.key或struct[key]代替structFind(struct,key)
• 请勿使用incrementValue()

Answer 1

我同意Tomalak关于过早优化的想法。比较不像“eq”那样可读。

话虽如此，Adobe开发人员中心有一篇关于ColdFusion性能的文章：http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html

Answer 2

• Compare() / CompareNoCase() ：在Java中，不区分大小写也比较昂贵。我会说这仍然适用。
• 不要使用evaluate() ：绝对 - 除非没有办法绕过它。大部分时间都有。
• 请勿使用Iif() ：我不能多说这个。我还是不使用它，因为它附带的整个DE()内容非常糟糕。
• struct.key超过StructFind(struct,key) ：我怀疑内部都使用相同的Java方法来获取结构项。 StructFind()只是堆栈上的另一个函数调用。我从来没有用过它，因为我不知道它带来了什么好处。我想这只是为了向后兼容。
• IncrementValue() ：我从未使用过那个。我的意思是，它是16个字符，甚至没有就地增加变量。这本来是它存在的唯一借口。

一些担忧属于“过早优化”角落，恕我直言。除了个人偏好或编码风格之外，我只会开始关注一个沉重的内循环中的一些细微之处，这会让应用程序陷入困境。

例如，如果你不需要一个不区分大小写的字符串比较，那么使用CompareNoCase()是没有意义的。但我会说99.9％的时间实际性能差异可以忽略不计。当然，您可以编写一个循环，对不同操作的100000次迭代进行计时，您会发现它们的表现不同。但在实际情况下，这些学术差异很少会产生任何可衡量的影响。

Answer 3

Coldfusion MX 8比所有帐户的MX 7快几倍。当它出现时，我阅读了很多意见，只是在不改变代码行的情况下升级性能提升是值得的......这是值得的。随着处理能力，内存可用性的提高，通常，您可以使用优化程度较低的代码执行更多操作。

这是否意味着我们应该停止关怀并写下什么？没有。机会是我们采取最快捷方式的地方，我们必须在那里发展最多的系统。

找到足够的工程设计之间的界线，而不是过度设计解决方案是一个很好的平衡。 Knuth在那里有一个引用我相信说“过早的优化是所有邪恶的根源”

对我而言，我试图将其作为基础：

• 将使用多少，
• 我的预期用户群的费用是多少，
• 对一切事物的重要性/重要性，
• 我多久会回到代码中将其扩展到其他区域

这些类型的想法越多地出现在“我或将会以某种方式”中，我会更加关注它。如果它需要具有可读性并且会产生小的性能影响，那么这是实现代码可持续性的更好方法。

否则，当我解决并构建真实（呃）价值的东西时，我会让物品争取我的注意力。

我们自己可以做的最大的好处是使用任何项目的框架，无论多小，从一开始就做小事。

这样一来，对于一个最初意味着暂时破解但从未被重新考虑过的系统重新开始工作没有任何恐惧感。