规则3经常让我和计算机科学专业的学生产生矛盾。我的教育背景是电子工程，通过底层（嵌入式C/ASM）进入软件开发，所以在职业生涯后期我才了解到大O符号和复杂度的正式定义。在我的职业生涯大部分时间里，坚持规则3是最合理的。当计算机科学专业的学生烦人地谈论大O符号时，他们通常会忘记n的值很小。但后来我的工作发生了变化。我开始从事不同的工作。突然之间，我的工作听起来更像人们抱怨的LeetCode面试。现在n真的很大，现在这真的很重要。请记住，罗布·派克来自一个不同的时代，那时为“大型机”编程看起来更像现在为嵌入式微控制器编程。
源讨论罗伯·派克的编程五规则原帖 448 条评论 · 导入时统计把你的经验，加入这段讨论。
我父亲曾用Fortran和各种类型的汇编语言进行编程。他总是偏爱查找表，因为它们可以取代复杂的条件判断或计算。在他那个时代，内存非常宝贵，但如果程序需要重复执行某些操作（大多数程序都是如此），那还是值得的。
完整原文我实际上不同意规则3！虽然数字通常都很小，但对小规模情况的快速处理通常不如在大规模情况下表现良好那么重要。因此，我更倾向于选择更好的大O复杂度，这样在现实世界中的极端情况下不会变得不可接受。（这类工作负载开发人员通常不会遇到，但你的大客户会遇到。） 当然，这需要权衡，实现两种选项所需的工程时间是一个重要的考虑因素。但鉴于两种算法都相对容易实现，我会选择在大尺寸下更快的那个，即使它在常见尺寸下较慢。我怀疑有一种隐含的假设，即“花哨”的算法需要更长时间且更难实现。但在许多情况下，两种算法都在标准库中，只需选择即可。如果这篇文章专注于“花哨”在实际时间上的意义，…
完整原文嗯，它用“花哨”这个词来表达。我认为一种善意的解读是理解问题领域。如果N始终很小，那么试图最小化大O复杂度只是在炫耀，而且在很多方面可能是适得其反的。如果N很大，这可能是一个要求。 大多数人不需要用于大数乘法的FFT算法，Karatsuba算法就足够了。但在某些领域，差异确实很重要。 我个人经常看到相反的效果——人们首先选择过于幼稚的方法，实现了一些O(n^2)的算法，而实际上实现O(n)或O(n log n)的算法并不会更复杂。而且n几乎总是很小，所以它运行得不错，直到突然崩溃。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。