Performance Hints (2023)

This formatting is more intuitive to me.

  L1 cache reference                   2,000,000,000 ops/sec
  L2 cache reference                   333,333,333 ops/sec
  Branch mispredict                    200,000,000 ops/sec
  Mutex lock/unlock (uncontended)      66,666,667 ops/sec
  Main memory reference                20,000,000 ops/sec
  Compress 1K bytes with Snappy        1,000,000 ops/sec
  Read 4KB from SSD                    50,000 ops/sec
  Round trip within same datacenter    20,000 ops/sec
  Read 1MB sequentially from memory    15,625 ops/sec
  Read 1MB over 100 Gbps network       10,000 ops/sec
  Read 1MB from SSD                    1,000 ops/sec
  Disk seek                            200 ops/sec
  Read 1MB sequentially from disk      100 ops/sec
  Send packet CA->Netherlands->CA      7 ops/sec

The HN title here is currently “Performance Hints (2023)”, but this was only published externally recently (2025). (See e.g. https://x.com/JeffDean/status/2002089534188892256 announcing it.) And of course 2023 is when the document was first created, but much of the content is more recent than that. So IMO it's a bit misleading to put "(2023)" in the title.

Really helps to have all this good info in one page. I often find myself focusing on few aspects here while ignoring the rest. Definitely saved to remind myself that there is a lot more to performance that the few tricks I know.

I wish Google would open source their gtl library. Similar utilities exist elsewhere but not in the same consistent quality and well-integrated package.

I particularly like the “what to do for flat profiles” ad “protobuf tips” sections. Similar advice distilled to this level is difficult to find elsewhere.

Wonderful article. I wish more people had this pragmatic approach when thinking about performance

Interesting that the blog only runs until 2023. Have they been absorbed by AI, Rust, or both?

I think I'd rather be eaten by a giant crustacean than work on AI.

Some of this can be reduced to a trivial form, which is to say practiced in reality on a reasonable scale, by getting your hands on a microcontroller. Not RTOS or Linux or any of that, but just a microcontroller without an OS, and learning it and learning its internal fetching architecture and getting comfortable with timings, and seeing how the latency numbers go up when you introduce external memory such as SD Cards and the like. Knowing to read the assembly printout and see how the instruction cycles add up in the pipeline is also good, because at least you know what is happening. It will then make it much easier to apply the same careful mentality to this which is ultimately what this whole optimization game is about - optimizing where time is spent with what data. Otherwise, someone telling you so-and-so takes nanoseconds or microseconds will be alien to you because you wouldn’t normally be exposed to an environment where you regularly count in clock cycles. So consider this a learning opportunity.