Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance Hints

abseil.io

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Performance Hints

#41

Post by svat »

zahlman wrote: post #40
svat wrote: post #33

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.

If the numbers come from analyzing performance in 2023, that seems more important than the external publication time.

The page is about tips for writing fast code. Much of it applied 20 years ago, and will apply 20 years from now. If by "the numbers" you mean specifically just the table ("rough costs for some basic low-level operations") in the "Estimation" section (which accounts for less than 0.5% of the words on the page), then that table was initially created in 2007, and is up-to-date as of 2025. Other numbers on the page are given with their dates, like 2001 and so on. So 2023 does not seem relevant in any way.

Re: Performance Hints

#42

Post by andrewf »

zahlman wrote: post #39
barchar wrote: post #30

Earlier quoted context omitted.

This is not always true. Compilers are quite good at register allocation but sometimes they get it wrong and sometimes you can make small changes to code that improve register allocation and thus performance. Usually the problem is an unfortunately placed spill, so the operation is actually l1d$ traffic, but still.

> l1d$ I don't know how to interpret this.

Level 1 data cache

Re: Performance Hints

#43

Post by dang »

svat wrote: post #33

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.

(Ok, we've belatedly taken 2023 out of the title now)

Re: Performance Hints

#44

Post by menaerus »

jesse__ wrote: post #15

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

I actually wish the audience to take the opposite, or perhaps a more balanced view. Being pragmatic is like taking an extreme view and as much as this article is a great resource, and contains some legit advice otherwise difficult to find elsewhere in such a concise form, folks need to be aware that this advice is what Google found for their unfathomable scale codebase to gain some real world benefits.

The things this article is describing are more nuanced than just "think about the performance sooner than latter". I say this as someone who does these kind of optimizations for a living and all too often I see teams wasting time trying to micro-optimize codepaths which by the end of the day do not provide any real demonstrable value.

And this is a real trap you can get into really easily if you read this article as a general wisdom, which is not.

Re: Performance Hints

#45

Post by dredmorbius »

danlark1 wrote: post #34
svat wrote: post #33

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.

Surprisingly I didn't put 2023, it was merged with another submission possibly with the help of mods

FYI: It's possible for that to be edited by others.

Re: Performance Hints

#46

Post by jcelerier »

twotwotwo wrote: post #7
xnx wrote: post #2

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,62…

Your version only describes what happens if you do the operations serially, though. For example, a consumer SSD can do a million (or more) operations in a second not 50K, and you can send a lot more than 7 total packets between CA and the Netherlands in a second, but to do either of those you need to take advantage of parallelism. If the reciprocal numbers are more intuitive for you you can still say an L1 cache refe…

> Your version only describes what happens if you do the operations serially, though

and that's what the intuition should be based on, because serial problems sadly exist and a lot of common wisdom suddenly disappear when confronted to one.

Post reply on HN