许多旧的冷聚变性能警告仍然适用于CFMX 8吗?

• Compare() / CompareNoCase() 比较敏感的病例在爪哇也比较贵。我想说这仍然是真的。
• 不要使用 evaluate() 当然-除非没有办法。大多数时候都是这样。
• 不要使用 Iif() 我不能说太多关于这个。不管怎样我都不用它,因为整个 DE() 它附带的东西太糟糕了。
• struct.key 结束 StructFind(struct,key) 我猜想内部都使用相同的Java方法来获取一个结构项。 StructFind() 只是堆栈上的另一个函数调用。我从来没有用过它,因为我不知道它会带来什么好处。我想这只是为了向后兼容。
• IncrementValue() 我从没用过那个。我的意思是,它是16个字符,甚至不会就地增加变量。这是它存在的唯一借口。

一些关注点落在“过早优化”的角落,imho。除了个人偏好或编码风格之外,我只会开始关心应用程序中一个沉重的内部循环中的一些微妙之处。

例如,如果你没有 需要 不区分大小写的字符串比较,使用 比较元() . 但我认为99.9%的时间,实际的性能差异是可以忽略的。当然,您可以编写一个循环,它乘以100000次不同操作的迭代,您会发现它们的执行方式不同。但在现实生活中,这些学术差异很少产生任何可测量的影响。

我同意托马拉克关于过早优化的想法。比较不如“eq”可读。

尽管如此,在Adobe开发者中心有一篇关于ColdFusion性能的伟大文章: http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html

ColdFusion MX 8比所有客户的MX 7快几倍。当它出来的时候,我读到很多观点,简单地升级以提高性能而不改变一行代码是非常值得的…这是值得的。随着处理能力、内存可用性的提高,通常情况下,使用不太优化的代码可以做得更多。

这是否意味着我们应该停止关心和写什么?不可能。我们走捷径的可能性最大,我们必须在那里扩大系统。

找到足够工程和不过度工程之间的界限是一个很好的平衡。克努斯有句话,我相信是这样说的 “过早的优化是万恶之源”

对我来说,我试着把它建立在:

• 要用多少钱,
• 在我预期的用户群中,这将是多么昂贵,
• 它对每件事都有多重要/重要,
• 我多久会回到代码中,把它扩展到其他区域

这些类型的想法越多地存在于“可能或以某种方式或另一种方式”,我就越关注它。如果需要可读性和小的性能影响结果,那么这是实现代码可持续性的更好方法。

否则,当我解决和构建具有实际(ER)价值的事物时,我会让事物为我的注意力而斗争。

我们能为自己做的最大的一个好处就是在任何项目中使用一个框架,不管这个框架有多小,并且从一开始就做正确的小事情。

这样一来,在一个原本是临时黑客但从未被重新考虑过的系统上重新工作,就没有什么可怕的了。