每个开发者都必须知道的 14 个数字
Jeff Dean , 一位著名的 Google 工程师, 推出了一个 每个人都必须知道的数字 的潜在数字列表。这个列表对设计大型基础架构的系统是一个巨大的资源。 算法及其复杂性总是会在计算机系统的关键部分出现,但我发现很少有工程师对一个O(n!)级算法相较一个 O(n5) 算法会怎样有很好的理解。 在编码比赛世界里,竞争选手一直在考虑这些优化权衡。毫不奇怪,有一组每个算法设计者都应该知道的数字。 |
super0555
|
下面的表格显示了不同复杂度算法条件下,在几秒钟内它们可以达到的极限,n是输入量大小。我已经为每个复杂的类型增加了一些算法和数据结构的例子。
这些数字不是非常精确,它们假设了内存操作以及一些变化的常数因子,但对于找到与你的问题和数据量大小相适应的解决方案研究方面,它们确实给出了一个很好的起点。 |
super0555
|
让我们通过一个实例来继续讲解。 假设你为一家GPS公司工作,你的项目是改善他们的导航功能。在学校,你学会使用Dijkstra's 算法,在图上计算两点之间的最短距离。了解这些数字,你就会明白,他将耗费几秒钟以计算具有上百万条边的图形,Dijkstra's 算法实现这些,有的时间复杂度(m代表边数,n表示节点数)。 现在你面临一个新的问题: 你期望你的代码能执行多块?几秒钟?数百毫秒? 如果它在网络上的响应时间少于500毫秒,就觉得快。因此我们选半秒。 图有多大?你想解决问题是一个城市,一个国家还是一片大陆? |
等PM
|
每一个大于其他大小的,将通过不同的方法解决。
比方说,我们要解决整个欧洲的问题。
下面是一些输入集的大小:
input | Europe | USA/CAN | USA (Tiger) |
---|---|---|---|
#nodes | 18 029 721 | 18 741 705 | 24 278 285 |
#directed edges | 42 199 587 | 47 244 849 | 58 213 192 |
#road categories | 13 | 13 | 4 |
即使我们选择半秒时间作为我们的执行时间,我们选的问题大小大约是4千万条边数,从我们提供的表里哼清楚地看到, m log n 太慢了。因此纯Dijkstra 算法解决不了我们的问题。我们需要卡看别的算法,如A星搜索算法或者基于 对于这个问题的高速公路层次式的表现。