1. 你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。
2. 估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
3. 花哨的算法在 n 很小时通常很慢，而 n 通常很小。花哨算法的常数复杂度很大。除非你确定 n 总是很大，否则不要用花哨算法（即使 n 很大，也优先考虑原则 2 ）。
4. 花哨的算法比简单算法更容易出 bug 、更难实现。尽量使用简单的算法配合简单的数据结构。
5. 数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。
6. 没有原则 6 。

Ken Thompson —— Unix 最初版本的设计者和实现者，禅宗偈语般地对 Pike 的原则4 作了强调：

拿不准就穷举

via: newsmth-algorithm

© zhiqiang for 阅微堂, 2008. | 链接 | 12 条评论

已经一个n，m和里n个数，设计一种保存这n个元素的表的数据结构形式，使得对中任何一个数，可以最少的查询次数（每次查询，可以选择一个位置，然后你能知道表中这个位置的数据），获知这个数是否在表中。

如果设计这个表为有序表，用二分法需要次查询。

有序表是最优的么？

举一个例子，一个保存1，2，3里面的两个数的有序表，要想知道2是否在这个表里面，至少需要两次查询。可不可以用一种特定的数据结构，使得一次查询就能判定任何一个数是不是在数据库里面？

结论是可能的，见下图：

一般的，假如表里的n个数的范围是1，2，...，2n-2，即，可以设计一种方法，使得，对于任何一个数，只需要查询一次，便能知道这个数是否在这个表里面。

课堂上有同学当场就想出设计方法，向他致敬！

另外，利用广义的Ramsey定理，对于固定的n，能够证明当m足够大时，无论你怎么设计那个表的结构，也至少需要的查询次数。

一个很神奇的问题。相关论文Should Table be Sorted?, 上面的图片也来自这篇文章。

© zhiqiang for 阅微堂, 2007. | 链接 | 5 条评论