1

Donald Knuth 说过“过早的优化是万恶之源”，我逐渐相信了这句话。

所以我可以说写应用程序时，我们应该专注于完成功能，而不考虑性能问题，直到我们不能忍受低性能？

恐怕如果我多次使用错误的模式会减慢应用程序的速度，因此修复问题可能会花费大量时间。我应该在广泛使用之前测试模式的性能吗？

我提到的模式可能是指使用 Linq 或 for-loop，使用Delegate.BeginInvoke, Parallel.For, or Task<T>，处理IDisposable或忽略它等。

欢迎任何参考资料。

4

2 回答 2

2

我同意 Knuth 引用的关于过早优化的精神，因为它会导致代码在开发初期变得过于复杂和笨拙，从而影响代码的质量和完成项目所需的时间。

我对您的帖子有两个担忧：

您应该了解您的函数/算法在理论上是否可以扩展/执行以满足您的要求（例如，您的解决方案的 O 复杂性 -> http://en.wikipedia.org/wiki/Analysis_of_algorithms）

您提到的模式实际上是具体的实现项，其中只有一些与性能有关，例如

  • Parallel.For/Task - 这些对于在多核系统上获得性能很有用
  • IDisposable - 这是与资源管理相关的，而不是要避免的事情
  • Linq vs. for-loop - 这可以是一个点优化，但您需要对您的用例进行基准测试/评估以确定哪个最适合您（例如，在某些情况下，Linq 可以移动到 PLinq 以实现并行性）
  • Delegate.BeginInvoke - 线程同步的非可选组件
于 2013-01-27T14:23:38.537 回答
1

永远不要在不关心性能的情况下编写代码。
性能代码直到代码变得更复杂（例如并行）。
但在 C# 5.0 中，甚至并行并不复杂。
如果您有一些您认为可能需要优化的电话，请为此进行设计。
设计代码，以便优化不会更改方法的接口。

有速度、内存、并发性（如果是服务器应用程序）、可靠性、安全性和支持。
干净的代码通常是最好的代码。

在您知道自己有性能问题之前不要发疯，但不要马虎。

在回答关于 SO 的另一个问题时，我告诉那个人他们不需要 DataTable，DataReader 会更快，内存更少。他们的反应是它仍然以每秒 1/2 的速度运行，我不在乎。对我来说，这是草率的代码。

@JonhSanders 我不同意“直到代码变得更复杂之前的性能代码”会导致错误或不完整。对我来说，性能编码与优化不同。首先传递任何东西，但丢弃我为性能编写的代码 - 没有什么奇异的，只是最佳实践。在我看到可能需要返回并优化的潜在热点的地方，我在编写时会考虑到优化。PS我同意结束这个问题。

于 2013-01-27T16:40:25.380 回答