我们都知道过早的优化是万恶之源，因为它会导致代码不可读/不可维护。更糟糕的是悲观，当有人实施“优化”时，因为他们think它会更快，但最终会更慢，而且有错误、难以维护等等。您见过的最荒谬的例子是什么？
我认为“过早优化是万恶之源”这句话已经被过度使用了。对于许多项目来说，这已经成为直到项目后期才考虑性能的借口。
这句话常常成为人们逃避工作的拐杖。我看到当人们真正应该说“哎呀，我们真的没有事先想到这一点并且现在没有时间处理它”时使用这句话。
我见过更多“荒谬”的愚蠢性能问题的例子，而不是由于“悲观”而引入的问题的例子
- 在程序启动期间读取相同的注册表项数千次（或数十万次）。
- 加载相同的 DLL 数百或数千次
- 不必要地保留文件的完整路径，浪费兆字节的内存
- 没有组织数据结构，因此它们占用的内存比所需的多
- 调整存储文件名或 MAX_PATH 路径的所有字符串的大小
- 对具有事件、回调或其他通知机制的事物进行无偿轮询
我认为更好的说法是：“没有测量和理解的优化根本不是优化——它只是随机变化”。
良好性能的工作非常耗时——通常比功能或组件本身的开发更耗时。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
