Performance Zone is brought to you in partnership with:

Creator of the Apache Tapestry web application framework and the Apache HiveMind dependency injection container. Howard has been an active member of the Java community since 1997. He specializes in all things Tapestry, including on-site Tapestry training and mentoring, but has lately been spreading out into fun new areas including functional programming (with Clojure), and NodeJS. Howard is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

Every Programmer Should Know These Latency Numbers

06.12.2012
| 113325 views |
  • submit to reddit

This is interesting stuff; Jonas Bonér organized some general some latency data by Peter Norvig as a Gist, and others expanded on it. What's interesting is how, scaling time up by a billion, converts a CPU instruction cycle into approximately one heartbeat, and yields a disk seek time of "a semester in university".

### Latency numbers every programmer should know
    L1 cache reference ......................... 0.5 ns
    Branch mispredict ............................ 5 ns
    L2 cache reference ........................... 7 ns
    Mutex lock/unlock ........................... 25 ns
    Main memory reference ...................... 100 ns
    Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
    Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
    SSD random read ........................ 150,000 ns = 150 µs
    Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
    Round trip within same datacenter ...... 500,000 ns = 0.5 ms
    Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms
    Disk seek ........................... 10,000,000 ns = 10 ms
    Read 1 MB sequentially from disk .... 20,000,000 ns = 20 ms
    Send packet CA->Netherlands->CA .... 150,000,000 ns = 150 ms

Assuming ~1GB/sec SSD

![Visual representation of latencies](http://i.imgur.com/k0t1e.png)

Visual chart provided by [ayshen](https://gist.github.com/ayshen)

Data by [Jeff Dean](http://research.google.com/people/jeff/)

Originally by [Peter Norvig](http://norvig.com/21-days.html#answers)

Lets multiply all these durations by a billion:

Magnitudes:

### Minute:
    L1 cache reference 0.5 s One heart beat (0.5 s)
    Branch mispredict 5 s Yawn
    L2 cache reference 7 s Long yawn
    Mutex lock/unlock 25 s Making a coffee

### Hour:
    Main memory reference 100 s Brushing your teeth
    Compress 1K bytes with Zippy 50 min One episode of a TV show (including ad breaks)

### Day:
    Send 2K bytes over 1 Gbps network 5.5 hr From lunch to end of work day

### Week
    SSD random read 1.7 days A normal weekend
    Read 1 MB sequentially from memory 2.9 days A long weekend
    Round trip within same datacenter 5.8 days A medium vacation
    Read 1 MB sequentially from SSD 11.6 days Waiting for almost 2 weeks for a delivery

### Year
    Disk seek 16.5 weeks A semester in university
    Read 1 MB sequentially from disk 7.8 months Almost producing a new human being
    The above 2 together 1 year

### Decade
    Send packet CA->Netherlands->CA 4.8 years Average time it takes to complete a bachelor's degree

 

 

Published at DZone with permission of Howard Lewis Ship, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Neo Nisa replied on Thu, 2012/06/21 - 11:29am

Thnks..... I got it....

Phil Whelan replied on Thu, 2012/07/26 - 9:28pm

I saw 200ms TCP latency from Japan to AWS Virginia while testing out out Heroku, which was equating to 1s delay on HTTP requests even with http keep-alive. What's funny is HerokuJP is just Heroku and so for Japanese devs they have to put up with this horrible latency if they want to use the service.

 

Sergej Riewe replied on Wed, 2013/01/09 - 6:58am

Really great! Thanks

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.