…前几天我遇到了一个类似的情况。我想做一个小的半协作式的项目计划。我找到了一个不错的工具，试用了一会儿，觉得它有我需要的功能，而且速度也足够。然后我决定做实际的计划。当系统中的条目数量从10-20增加到30-40时，我开始觉得有点卡顿。到了50-60条，更加卡顿了。这时候我已经投入了，所以忍受了这个工具几个月，因为它在处理100条数据时界面不断崩溃。如果一开始就知道会发生这种情况，我会寻找其他工具。但相反，我掉进了一个隐藏的O(n^2)问题里，现在我对这个产品充满了厌恶。
源讨论“整洁”的代码，糟糕的性能原帖 907 条评论 · 导入时统计月亮不会掉进海洋，直到它掉进海洋。
完整原文把你的经验，加入这段讨论。
这不仅仅是这样。现代软件中黑盒组合的实现方式是，你的n=100代码（比如一个组件）会被重复使用到上面的某个地方，现在你被迭代了m=100次。哎呀，现在n=10k了。 通常，Casey提倡整体性思维，找到正确的思维模型，然后编写最直接的代码（这比看起来要难；人们经常在巨大的解决方案状态空间中分心）。然而这需要1. 一个小型团队和2. 优秀的工程师。人们争论说这并不总是可行，这是真的，但这些演讲的目的是传播编码模式和知识，以培养下一代工程师，让他们更了解这些问题，并朝着更小的团队和更好的工程师方向努力，尽管我们可能永远无法达到这个目标。大多数现代模式（和组织结构）并不鼓励这样做…
完整原文大约一年前，在Julia编译器中有一个有趣的例子。 编译器的一部分在`let`块嵌套深度上是O(N^2)的。也就是说 let x = foo(), y = y, z = 2y ... end 嵌套深度是3。这似乎不应该是个问题，N永远不会是10，更不用说100了，对吧？ 直到突然间，某些由建模软件生成的关键代码中，`N`达到了数千，因此处理`let`引入的作用域突然成为了编译时间的主要负担...
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。