14 numbers every developer should know
来源:互联网 发布:淘宝开店详细流程 编辑:程序博客网 时间:2024/05/01 20:09
Jeff Dean , a famous Google engineer, popularized a list of latency numbers everyone should know. The list is a great resource for designing large scale infrastructure systems.
Algorithms and their complexity often occur in critical parts of computer systems, but I find that few engineers have a good understanding of how a O(n!) algorithm compares to a O(n5) one.
In the coding contest world, competitors think about these tradeoffs all the time. No wonder, there's a set of numbers every algorithm designer should know.
The table below shows the limits that can be reached in a few seconds by algorithms of different complexities, n being the input size. I've added some algorithms and data structure examples for each complexity class.
These numbers aren't very precise, they assume in memory operations and some varying constant factors, but they do give a good starting point in your search for a solution that fits your problem and your data size.
Let's go through an example.
Suppose you work for a GPS company and your project is to improve their directions feature. In school you've learned about using Dijkstra's algorithm to find the shortest path between two nodes in a graph. Knowing these numbers you will understand that it will take seconds to process a graph with millions of edges given that Dijkstra implementations have m log n time complexity (where m is the number of edges and n the number of nodes).
Now you face a few questions:
How fast do you want your code to be? seconds? hundreds of milliseconds?
A response on the web feels fast if it takes less then 500 milliseconds. So let's pick half a second.
How big is the graph? Do you want to solve the problem for a city, a coutry or even a continent?
Each is about a magnitude larger than the other and will be solved by different approaches. Let's say we want to solve the problem for the whole of Europe.
Here are sizes for a few input sets:
Since we chose half a second to be our execution time and the size of our problem to be about 40 million edges it's clear from our table that m log n is too slow. So pure Dijkstra won't do. We need to look at how other algorithms like A star search or one based on Highway hierarchies behave for this problem.
- 14 numbers every developer should know
- Six Things Every jQuery Developer Should Know
- 10 Programming Proverbs Every Developer Should Know
- 10 Programming Proverbs Every Developer Should Know
- Linux Commands Every Developer Should Know
- 10 Programming Proverbs Every Developer Should Know
- 5 tips every Unity developer should know
- 10 Linux Commands Every Developer Should Know
- Latency Numbers Every Programmer Should Know
- [转载]Latency Numbers Every Programmer Should Know
- Latency numbers every programmer should know
- Every Programmer Should Know These Latency Numbers
- Every Programmer Should Know These Latency Numbers
- Standard Programs That Every ABAP Developer Should Know
- [Linux Journal]Ten Commands Every Linux Developer Should Know
- Eight Isolation Levels Every Web Developer Should Know
- 10 Things Every Senior Flex Developer Should Know
- Eight Isolation Levels Every Web Developer Should Know
- EasyUI 动态tab页界面小结
- Makefile 管理工具 — Automake and Autoconf
- Yii Using 3rd-Party Libraries(使用第三方库)
- log4net 使用
- 不定式作主语
- 14 numbers every developer should know
- CentOS访问Windows共享文件夹的两种方法 .
- Cocos2d-x3.0之路--01(说些题外话)
- 这突然的问话让潇雨菲怔
- “镜雅,我可以这么
- 青剑的脸也随之变色,相
- 光场相机介绍
- 写在Wolf&Sheep狼爱上羊上架APP Store前
- 清醒