在java中,他们说不要连接字符串,而是应该创建一个字符串缓冲区并继续添加它,然后当你完成所有操作时,使用toString()从中获取一个String对象.这是我没有得到的.他们说出于性能原因这样做,因为连接字符串会产生大量临时对象.但如果目标是性能,那么你就会使用像C/C++或汇编这样的语言.
使用java的论点是,购买速度更快的处理器比支付高级程序员编写快速高效的代码便宜得多.所以一方面,你应该让硬件处理效率低下的问题,但另一方面,你应该使用字符串缓冲来提高java的效率.
虽然我看到你可以做到这两点,但是使用java和stringbuffers,我的问题是你要么使用更快的芯片还是花费额外的时间编写更高效的软件,那么逻辑上存在缺陷.
开发人员应该了解性能影响的他们的编码选择.
编写导致非线性性能的算法并不是非常困难 - 多项式,指数或更差.如果您在某种程度上不理解语言,编译器和库如何支持您的算法,您可能陷入陷阱,没有多少处理能力会让您厌倦.运行时或内存使用量呈指数级的算法可以快速超过任何硬件在合理时间内执行的能力.
假设硬件可以扩展到设计不佳的算法/编码选择是一个坏主意.例如,一个循环将100,000个小字符串连接在一起(比如说成一个XML消息).这不是一种罕见的情况 - 但是当使用单个字符串连接(而不是StringBuffer)实现时,这将导致99,999个垃圾收集器必须处理的大小增加的中间字符串.如果没有足够的内存,这很容易使操作失败 - 或者最好只是永远运行.
现在在上面的例子中,一些Java编译器通常(但不总是)重写代码以在幕后使用StringBuffer - 但这是例外,而不是规则.在许多情况下,编译器根本无法推断开发人员的意图 - 编写高效代码成为开发人员的责任.
最后一条评论 - 编写高效代码并不意味着花费所有时间来寻找微优化. 过早优化是编写好代码的敌人.但是,您不应该将过早优化与在时间/存储方面理解算法的O()性能以及在哪种情况下使用哪种算法或设计做出良好选择相混淆.
作为开发人员,您不能忽视这一级别的知识,只是假设您总是可以在其上投入更多硬件.