alt.hn

1/1/2026 at 2:39:23 PM

Python numbers every programmer should know

 https://mkennedy.codes/posts/python-numbers-every-programmer-should-know/

by WoodenChair

1/1/2026 at 7:11:14 PM

A lot of people here are commenting that if you have to care about specific latency numbers in Python you should just use another language.

I disagree. A lot of important and large codebases were grown and maintained in Python (Instagram, Dropbox, OpenAI) and it's damn useful to know how to reason your way out of a Python performance problem when you inevitably hit one without dropping out into another language, which is going to be far more complex.

Python is a very useful tool, and knowing these numbers just makes you better at using the tool. The author is a Python Software Foundation Fellow. They're great at using the tool.

In the common case, a performance problem in Python is not the result of hitting the limit of the language but the result of sloppy un-performant code, for example unnecessarily calling a function O(10_000) times in a hot loop.

I wrote up a more focused "Python latency numbers you should know" as a quiz here https://thundergolfer.com/computers-are-fast

by thundergolfer

1/2/2026 at 8:51:27 AM

I do performance optimization for a system written in Python. Most of these numbers are useless to me, because they’re completely irrelevant until they become a problem, then I measure them myself. If you are writing your code trying to save on method calls, you’re not getting any benefit from using the language and probably should pick something else.

by saagarjha

1/2/2026 at 11:49:31 AM

It's always a balance.

Good designs do not happen in a vacuum but informed with knowledge of at least the outlines of the environment.

One can have a breakfast pursuing an idea -- let me spill some sticky milk on the dining table, who cares, I will clean up if it becomes a problem later.

Another is, it's not much of an overbearing constraint not to make a mess with spilt milk in the first place, maybe it will not be a big bother later, but it's not hurting me much now, to be not be sloppy, so let me be a little hygienic.

There's a balance between making a mess and cleaning up and not making a mess in the first place. The other extreme is to be so defensive about the possibility of creating a mess that it paralyses progress.

The sweet spot is somewhere between the extremes and having the ball-park numbers in the back of one's mind helps with that. It informs about the environment.

by srean

1/1/2026 at 11:21:54 PM

No.

Python’s issue is that it is incredibly slow in use cases that surprise average developers. It is incredibly slow at very basic stuff, like calling a function or accessing a dictionary.

If Python didn’t have such an enormous number of popular C and C++ based libraries it would not be here. It was saved by Numpy etc etc.

by Scubabear68

1/2/2026 at 11:11:46 AM

I'm not sure how Python can be described as "saved" by numpy et al., when the numerical Python ecosystem was there near the beginning, and the language and ecosystem have co-evolved? Why didn't Perl (with PDL), R or Ruby (or even php) succeed in the same way?

by aragilar

1/2/2026 at 12:12:38 PM

22ns for a function call and dictionary key lookup, that's actually surprisingly fast.

by HenriTEL

1/2/2026 at 6:55:33 PM

In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results.

3 times.

This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down.

Turns out, when you use programming languages that are fit for purpose, you don't have to obsess over every function call, because computers are fast.

I think people vastly underestimate how slow python is.

We are rebuilding an internal service in Java, going from python, and our half assed first attempts are over ten times faster, no engineering required, exactly because python takes forever just to call a function. The python version was dead, and would never get any faster without radical rebuilds and massive changes anyway.

It takes python 19ns to add two integers. Your CPU does it in about 0.3 ns..... in 2004.

That those ints take 28 bytes each to hold in memory is probably why the new Java version of the service takes 1/10th the memory as well.

by mrguyorama

1/3/2026 at 8:08:13 PM

22ns might be about 100 processor instructions. Somehow I doubt that any programming language can parse 50 strings in 100 instructions, let alone with naive code.

by igiveup

1/5/2026 at 4:22:36 PM

You are right.

I have said something very wrong. Java may be fast but it isn't magic.

What I claimed is not possible and I should have realized that.

I can not correct my previous claim. I wish HN had longer edit windows and I wish HN allowed you to downvote older comments.

I cannot erase this wrong info

by mrguyorama

1/3/2026 at 10:54:52 AM

Python is slow but in my experience (that mostly relates to web services and data processing) I found that I/O was by far the biggest bottleneck. Waiting for the database, another http service or local storage, which often takes more than 1ms anyway.

by HenriTEL

1/3/2026 at 4:19:40 PM

Yep.

Except when it’s not I/O.

by Scubabear68

1/2/2026 at 4:02:54 AM

i hate python but if your bottleneck is that sqlite query, optimizing a handful of addition operations is a wash. thats why you need to at least have a feel for these tables

by dnautics

1/2/2026 at 12:47:33 AM

Agreed, and on top of that:

I think these kind of numbers are everywhere and not just specific to Python.

In zig, I sometimes take a brief look to the amount of cpu cycles of various operations to avoid the amount of cache misses. While I need to aware of the alignment and the size of the data type to debloat a data structure. If their logic applies, too bad, I should quit programming since all languages have their own latency on certain operations we should aware of.

There are reasons to not use Python, but that particular reason is not the one.

by NoteyComplexity

1/1/2026 at 7:21:52 PM

I think both points are fair. Python is slow - you should avoid it if speed is critical, but sometimes you can’t easily avoid it.

I think the list itself is super long winded and not very informative. A lot of operations take about the same amount of time. Does it matter that adding two ints is very slightly slower than adding two floats? (If you even believe this is true, which I don’t.) No. A better summary would say “all of these things take about the same amount of time: simple math, function calls, etc. these things are much slower: IO.” And in that form the summary is pretty obvious.

by oofbey

1/1/2026 at 7:45:18 PM

I think the list itself is super long winded and not very informative.

I agree. I have to complement the author for the effort put in. However it misses the point of the original Latency numbers every programmer should know, which is to build an intuition for making good ballpark estimations of the latency of operations and that e.g. A is two orders of magnitude more expensive than B.

by microtonal

1/1/2026 at 8:17:50 PM

our build system is written in python, and i’d like it not to suck but still stay in python, so these numbers very much matter.

by i_am_a_peasant

1/2/2026 at 6:10:22 AM

For some of these, there are alternative modules you can use, so it is important to know this. But if it really matters, I would think you'd know this already?

For me, it will help with selecting what language is best for a task. I think it won't change my view that python is an excellent language to prototype in though.

by notepad0x90

1/2/2026 at 11:34:54 AM

> ... a function O(10_000) times in a hot loop

O(10_000) is a really weird notation.

by TacticalCoder

1/2/2026 at 12:06:38 PM

Generously we could say they probably mean ~10_000 rather than O(10_000)

by tialaramex

1/3/2026 at 3:24:24 PM

I meant it as an order-of-magnitude notation, so means more like 10,000-90,000. Eg. calling the function 3,000 times is OK, but 30,000 is too much. Odd notation, yes, but I've picked it up somewhere along the way.

by thundergolfer

1/4/2026 at 6:38:54 PM

I think it follows naturally from speech. People say "order ten thousand" pretty naturally. Big-O notation is often vocalized as "order". But technically it's a a clash of ideas when written that way.

by oofbey

1/1/2026 at 7:21:38 PM

> A lot of important and large codebases were grown and maintained in Python

How does this happen? Is it just inertia that cause people to write large systems in a essentially type free, interpreted scripting language?

by nutjob2

1/1/2026 at 8:05:58 PM

Small startups end up writing code in whatever gets things working faster, because having too large a codebase with too much load is a champagne problem.

If I told you that we were going to be running a very large payments system, with customers from startups to Amazon, you'd not write it in ruby and put the data in MongoDB, and then using its oplog as a queue... but that's what Stripe looked like. They even hired a compiler team to add type checking to the language, as that made far more sense than porting a giant monorepo to something else.

by hibikir

1/1/2026 at 7:27:36 PM

It's very simple. Large systems start as small systems.

by xboxnolifes

1/1/2026 at 9:24:37 PM

Large systems are often aggregates of small systems, too.

by dragonwriter

1/1/2026 at 7:30:35 PM

It’s a nice and productive language. Why is that incomprehensible?

by oivey

1/1/2026 at 7:23:12 PM

It’s very natural. Python is fantastic for going from 0 to 1 because it’s easy and forgiving. So lots of projects start with it. Especially anything ML focused. And it’s much harder to change tools once a project is underway.

by oofbey

1/1/2026 at 7:57:30 PM

this is absolutely true, but there's an additional nuance: yes, python is fantastic, yes, it's easy and forgiving, but there are other languages like that too. ...except there really aren't. other than ruby and maybe go, every other popular language sacrifices ease of use for things that simply do not matter for the overwhelming majority of programs. much of python's popularity doesn't come from being easy and forgiving, it's that everything else isn't. for normal programming why would we subject ourselves to anything but python unless we had no choice?

while I'm on the soapbox I'll give java a special mention: a couple years ago I'd have said java was easy even though it's tedious and annoying, but I've become reacquainted with it for a high school program (python wouldn't work for what they're doing and the school's comp sci class already uses java.)

this year we're switching to c++.

by passivegains

1/1/2026 at 10:48:59 PM

Omg, switching to C++ for pupils programming beginners ... "How to turn off the most students from computer programming?" 101. Really can't get much worse than C++ for beginners.

by zelphirkalt

1/2/2026 at 2:31:17 AM

PSU (Oregon) uses C++ as just "c with classes" and ignores the rest of C++ for intro to programming courses. It frustrates people who already use C++ but otherwise works pretty well.

by nightfly

1/2/2026 at 2:35:42 PM

We should distinguish "First language" classes (for Computer Scientists who will likely learn many other languages and are expected to graduate knowing enough to just pick up another language with self study in reasonable time) from "Only language" classes for subjects where you might find it useful to write some software. These have different goals, it wouldn't make sense to teach say, OCaml as the only language but it's entirely reasonable as a first language.

by tialaramex

1/2/2026 at 12:16:50 PM

This was how we learned it in an intro class in highschool ages ago, worked pretty well there too.

by Izkata

1/2/2026 at 12:36:50 PM

C++, The Good Parts

by jgalt212

1/2/2026 at 6:41:49 PM

Back in the 1990's, C++ used to be taught at high school students and first year university students.

by pjmlp

1/3/2026 at 2:03:41 AM

I just went and checked my university - they’re still teaching c++ to first year uni students in 2025

by maccard

1/2/2026 at 6:40:53 PM

Cough, Lisp.

by pjmlp

1/1/2026 at 10:37:19 PM

Python has types, now even gradual static typing if you want to go further. It's irrelevant whether language is interpreted scripting if it solves your problem.

by wiseowise

1/1/2026 at 10:29:37 PM

Most large things begin life as small things.

by tjwebbnorfolk

1/1/2026 at 11:43:25 PM

Someone says "let's write a prototype in Python" and someone else says "are you sure we shouldn't use a a better language that is just as productive but isn't going to lock us into abysmal performance down the line?" but everyone else says "nah we don't need to worry about performance yet, and anyway it's just a prototype - we'll write a proper version when we need to"...

10 years later "ok it's too slow; our options are a) spend $10m more on servers, b) spend $5m writing a faster Python runtime before giving up later because nobody uses it, c) spend 2 years rewriting it and probably failing, during which time we can make no new features. a) it is then."

by IshKebab

1/2/2026 at 3:11:53 AM

What many startups need to succeed is to be able to pivot/develop/repeat very quickly to find a product+market that makes money. If they don't find that, and most don't, the millions you talk about never come due. They also rarely have enough developers, so developer productivity in the short term is vital to that iteration speed. If that startup turns into Dropbox or Instagram, the millions you mention are round-off error on many billions. Easy business decision, and startups are first and foremost businesses.

Some startups end up in between the two extremes above. I was at one of the Python-based ones that ended up in the middle. At $30M in annual revenue, Python was handling 100M unique monthly visitors on 15 cheap, circa-2010 servers. By the time we hit $1B in annual revenue, we had Spark for both heavy batch computation and streaming computation tasks, and Java for heavy online computational workloads (e.g., online ML inference). There were little bits of Scala, Clojure, Haskell, C++, and Rust here and there (with well over 1K developers, things creep in over the years). 90% of the company's code was still in Python and it worked well. Of course there were pain points, but there always are. At $1B in annual revenue, there was budget for investments to make things better (cleaning up architectural choices that hadn't kept up, adding static types to core things, scaling up tooling around package management and CI, etc.).

But a key to all this... the product that got to $30M (and eventually $1B+) looked nothing like what was pitched to initial investors. It was unlikely that enough things could have been tried to land on the thing that worked without excellent developer productivity early on. Engineering decisions are not only about technical concerns, they are also about the business itself.

by rented_mule

1/1/2026 at 11:49:51 PM

What language is “just as productive but isn't going to lock us into abysmal performance down the line”?

What makes that language not strictly superior to Python?

by gcanyon

1/2/2026 at 9:50:08 PM

Typescript, C#, Go, Rust.

I'd say they are almost strictly superior to Python, but there are some minor factors why you might still choose Python over those. E.g. arbitrary precision integers, or the REPL. Go is a bit tedious and Rust is harder to learn (but productive once you have).

But overall they would all be a better choice than Python. Yes even for startups who need to move fast.

by IshKebab

1/3/2026 at 11:19:53 PM

I say this out of genuine surprise, not judgment -- I never would have guessed that native Typescript is significantly faster than native Python. To be fair, I don't know if "significantly" is justified. I get that Typescript is typed (heh) and Python is not, but compared to my daily driver language (also not typed) Python is so much faster that I subconsciously think of typing as not being the major performance unlock. But I guess once you optimize the rest, typing is (nearly) the final boss of performance.

by gcanyon

1/2/2026 at 2:11:57 AM

Loose typing makes you really fast at writing code, as long as you can keep all the details in your head. Python is great for smaller stuff. But crossed some threshold, the lack of a mechanism that has your back starts slowing you down.

by nazgul17

1/2/2026 at 4:00:37 AM

Sure, my language of choice is more flexible than that: I can type

   put "test abc999 this" into x
   add 1 to char 4 to 6 of word 2 of x
   put x -- puts "test abc1000 this"
But I'm still curious -- what's the better language?

by gcanyon

1/2/2026 at 9:42:58 AM

If I made an app in python and in 10 years it grows so successful that it needs a $10m vertical scale or $5m rewrite, I wouldn't even complain.

by anhner

1/2/2026 at 2:52:34 AM

I don't know a better open source language than Python. Java and C# are both better (platforms) but they come with that obvious corporate catch.

by fud101

1/2/2026 at 6:44:13 PM

You can still get to use Scala, Kotlin, Clojure, F#, all with better performance than Python, and similar prototyping capabilities.

by pjmlp

1/3/2026 at 1:37:25 AM

Those are non-mainstream languages, I think the point stands. You would need to prove the case for Scala or Kotlin tbh, Scala is hideously complex and Kotlin like Python suffers from becoming too bloated, accumulating features and syntax that are either not required or difficult to remember. Clojure and F# are nice and all but very niche.

by fud101

1/3/2026 at 9:01:55 AM

Python being complex isn't an issue for beginners, apparently.

Kotlin owns the mobile development market with 80% Android market share.

Scala was the AI before Python with Hadoop, Spark and friends.

Lisps might be niche, yet they were Python's flexibility, with machine code compilers, since 1958.

by pjmlp

1/1/2026 at 4:38:45 PM

Counterintuitively: program in python only if you can get away without knowing these numbers.

When this starts to matter, python stops being the right tool for the job.

by fooker

1/1/2026 at 4:53:17 PM

Or keep your Python scaffolding, but push the performance-critical bits down into a C or Rust extension, like numpy, pandas, PyTorch and the rest all do.

But I agree with the spirit of what you wrote - these numbers are interesting but aren’t worth memorizing. Instead, instrument your code in production to see where it’s slow in the real world with real user data (premature optimization is the root of all evil etc), profile your code (with pyspy, it’s the best tool for this if you’re looking for cpu-hogging code), and if you find yourself worrying about how long it takes to add something to a list in Python you really shouldn’t be doing that operation in Python at all.

by libraryofbabel

1/1/2026 at 5:39:33 PM

"if you're not measuring, you're not optimizing"

by eichin

1/1/2026 at 6:33:48 PM

I agree. I've been living off Python for 20 years and have never needed to know any of these numbers, nor do I need them now, for my work, contrary to the title. I also regularly use profiling for performance optimization and opt for Cython, SWIG, JIT libraries, or other tools as needed. None of these numbers would ever factor into my decision-making.

by Demiurge

1/1/2026 at 8:14:21 PM

.....

You don't see any value in knowing that numbers?

by AtlasBarfed

1/2/2026 at 1:27:02 AM

That's what I just said. There is zero value to me knowing these numbers. I assume that all python built in methods are pretty much the same speed. I concentrate on IO being slow, minimizing these operations. I think about CPU intensive loops that process large data, and I try to use libraries like numpy, DuckDB, or other tools to do the processing. If I have a more complicated system, I profile its methods, and optimize tight loops based on PROFILING. I don't care what the numbers in the article are, because I PROFILE, and I optimize the procedures that are the slowest, for example, using cython. Which part of what I am saying does not make sense?

by Demiurge

1/2/2026 at 11:38:05 AM

That makes perfect sense. Especially since those numbers can change with new python versions.

by KeplerBoy

1/1/2026 at 9:02:57 PM

As others have pointed out, Python is better used in places where those numbers aren't relevant.

If they start becoming relevant, it's usually a sign that you're using the language in a domain where a duck-typed bytecode scripting-glue language is not well-suited.

by TuringTest

1/1/2026 at 4:42:13 PM

Exactly. If you're working on an application where these numbers matter, Python is far too high-level a language to actually be able to optimize them.

by MontyCarloHall

1/1/2026 at 6:39:12 PM

Why? I've build some massive analytic data flows in Python with turbodbc + pandas which are basically C++ fast. It uses more memory which supports your point, but on the flip-side we're talking $5-10 extra cost a year. It could frankly be $20k a year and still be cheaper than staffing more people like me to maintain these things, rather than having a couple of us and then letting the BI people use the tools we provide for them. Similarily when we do embeded work, micro-python is just so much easier to deal with for our engineering staff.

The interoperability between C and Python makes it great, and you need to know these numbers on Python to know when to actually build something in C. With Zig getting really great interoperability, things are looking better than ever.

Not that you're wrong as such. I wouldn't use Python to run an airplane, but I really don't see why you wouldn't care about the resources just because you're working with an interpreted or GC language.

by Quothling

1/1/2026 at 6:55:38 PM

> you need to know these numbers on Python to know when to actually build something in C

People usually approach this the other way, use something like pandas or numpy from the beginning if it solves your problem. Do not write matrix multiplications or joins in python at all.

If there is no library that solves your problem, it's a great indication that you should avoid python. Unless you are willing to spend 5 man-years writing a C or C++ library with good python interop.

by fooker

1/3/2026 at 12:22:10 PM

> People usually approach this the other way, use something like pandas or numpy from the beginning if it solves your problem.

That is exactly how we approach it though. We didn't start out with turbodbc + pandas, it started as an sql alchemy and pandas service. Then when it was too slow, I got involved, found and dealth with the bottle necks. I'm not sure how you would find and fix such things without knowing the efficiency or lack there of in different parts of Python. Also, as you'll notice, we didn't write ur own stuff, we simply used more efficient Python libraries.

by Quothling

1/1/2026 at 7:37:01 PM

People generally aren’t rolling their own matmuls or joins or whatever in production code. There are tons of tools like Numba, Jax, Triton, etc that you can use to write very fast code for new, novel, and unsolved problems. The idea that “if you need fast code, don’t write Python” has been totally obsolete for over a decade.

by oivey

1/1/2026 at 7:56:17 PM

Yes, that's what I said.

If you are writing performance sensitive code that is not covered by a popular Python library, don't do it unless you are a megacorp that can put a team to write and maintain a library.

by fooker

1/1/2026 at 8:02:20 PM

It isn’t what you said. If you want, you can write your own matmul in Numba and it will be roughly as fast as similar C code. You shouldn’t, of course, for the same reason handrolling your own matmuls in C is stupid.

Many problems can performantly solved in pure Python, especially via the growing set of tools like the JIT libraries I cited. Even more will be solvable when things like free threaded Python land. It will be a minority of problems that can’t be, if it isn’t already.

by oivey

1/1/2026 at 7:57:50 PM

From the complete opposite side, I've built some tiny bits of near irrelevant code where python has been unacceptable, e.g. in shell startup / in bash's PROMPT_COMMAND, etc. It ends up having a very painfully obvious startup time, even if the code is nearing the equivalent of Hello World

    time python -I -c 'print("Hello World")'
    real    0m0.014s
    time bash --noprofile -c 'echo "Hello World"'
    real    0m0.001s

by its-summertime

1/1/2026 at 8:38:58 PM

What exactly do you need 1ms instead of 14ms startup time in a shell startup? The difference is barely perceptible.

Most of the time starting up is time spent seartching the filesystem for thousands of packages.

by dekhn

1/1/2026 at 9:09:44 PM

> What exactly do you need 1ms instead of 14ms startup time in a shell startup?

I think as they said: when dynamically building a shell input prompt it starts to become very noticable if you have like 3 or more of these and you use the terminal a lot.

by NekkoDroid

1/1/2026 at 11:38:11 PM

Ah, I only noticed the "shell startup" bit.

Yes, after 2-3 I agree you'd start to notice if you were really fast. I suppose at that point I'd just have Gemini rewrite the prompt-building commands in Rust (it's quite good at that) or merge all the prompt-building commands into a single one (to amortize the startup cost).

by dekhn

1/2/2026 at 10:58:28 AM

https://starship.rs/ perhaps? I should probably start using it again honestly.

by its-summertime

1/2/2026 at 3:41:57 PM

it feels good to have all that information at your fingertips but most of the time the default config is way too noisy.

by fragmede

1/1/2026 at 8:15:07 PM

These basically seem like numbers of last resort. After you’ve profiled and ruled out all of the usual culprits (big disk reads, network latency, polynomial or exponential time algorithms, wasteful overbuilt data structures, etc) and need to optimize at the level of individual operations.

by bathtub365

1/2/2026 at 1:50:55 PM

Not at all.

Some of those number are very important:

- Set membership check is 19.0 ns, list is 3.85 μs. Knowing what data structure to use for the job is paramount.

- Write 1KB file is 35.1 μs but 1MB file is only 207 μs. Knowing the implications of I/O trade off is essential.

- sum() 1,000 integers is only 1,900 ns: Knowing to leverage the stdlib makes all the difference compared to manual loop.

Etc.

A few years ago I did a Python rewrite of a big clients code base. They had a massive calculation process that took 6 servers 2 hours.

We got it down to 1 server, 10 minutes, and it was not even the goal of the mission, just the side effect of using Python correctly.

In the end, quadratic behavior is quadratic behavior.

by BiteCode_dev

1/2/2026 at 5:30:43 PM

List membership check being significantly slower than set membership check is freshman computer science 101.

by fooker

1/1/2026 at 4:38:46 PM

I doubt there is much to gain from knowing how much memory an empty string takes. The article or the listed numbers have a weird fixation on memory usage numbers and concrete time measurements. What is way more important to "every programmer" is time and space complexity, in order to avoid designing unnecessarily slow or memory hungry programs. Under the assumption of using Python, what is the use of knowing that your int takes 28 bytes? In the end you will have to determine, whether the program you wrote meats the performance criteria you have and if it does not, then you need a smarter algorithm or way of dealing with data. It helps very little to know that your 2d-array of 1000x1000 bools is so and so big. What helps is knowing, whether it is too much and maybe you should switch to using a large integer and a bitboard approach. Or switch language.

by zelphirkalt

1/1/2026 at 8:13:38 PM

I disagree. Performance is a leaky abstraction that *ALWAYS* matters.

Your cognition of it is either implicit or explicit.

Even if you didn't know for example that list appends was linear and not quadratic and fairly fast.

Even if you didn't give a shit if simple programs were for some reason 10000x slower than they needed to be because it meets some baseline level of good enough / and or you aren't the one impacted by the problems inefficacy creates.

Library authors beneath you would still know and the APIs you interact with and the pythonic code you see and the code LLMS generate will be affected by that leaky abstraction.

If you think that n^2 naive list appends is a bad example its not btw, python string appends are n^2 and that has and does affect how people do things, f strings for example are lazy.

Similarly a direct consequence of dictionaries being fast in Python is that they are used literally everywhere. The old Pycon 2017 talks from Raymond talk about this.

Ultimately what the author of the blog has provided is this sort of numerical justification for the implicit tacit sort of knowledge performance understanding gives.

by kingstnap

1/1/2026 at 4:51:14 PM

> Under the assumption of using Python, what is the use of knowing that your int takes 28 bytes?

Relevant if your problem demands instatiation of a large number of objects. This reminds me of a post where Eric Raymond discusses the problems he faced while trying to use Reposurgeon to migrate GCC. See http://esr.ibiblio.org/?p=8161

by Qem

1/1/2026 at 5:37:27 PM

A meta-note on the title since it looks like it’s confusing a lot of commenters: The title is a play on Jeff Dean’s famous “Latency Numbers Every Programmer Should Know” from 2012. It isn’t meant to be interpreted literally. There’s a common theme in CS papers and writing to write titles that play upon themes from past papers. Another common example is the “_____ considered harmful” titles.

by Aurornis

1/1/2026 at 7:02:14 PM

Good callout on the paper reference, but this author gives gives every indication that he’s dead serious in the first paragraph. I don’t think commenters are confused.

by willseth

1/1/2026 at 8:43:09 PM

That doc predates 2012 significantly.

From what I've been able to glean, it was basically created in the first few years Jeff worked at Google, on indexing and serving for the original search engine. For example, the comparison of cache, RAM, and disk: determined whether data was stored in RAM (the index, used for retrieval) or disk (the documents, typically not used in retrieval, but used in scoring). Similarly, the comparison of California-Netherlands time- I believe Google's first international data cetner was in NL and they needed to make decisions about copying over the entire index in bulk versus serving backend queries in the US with frontends in the NL.

The numbers were always going out of date; for example, the arrival of flash drives changed disk latency significantly. I remember Jeff came to me one day and said he'd invented a compression algorithm for genomic data "so it can be served from flash" (he thought it would be wasteful to use precious flash space on uncompressed genomic data).

by dekhn

1/1/2026 at 6:10:23 PM

This title only works if the numbers are actually useful. Those are not, and there are far too many numbers for this to make sense.

by Kwpolska

1/1/2026 at 6:24:54 PM

The title was meant to be taken literally, as in you're supposed to memorize all of these numbers. It was meant as an in-joke reference to the original writing to signal that this document was going to contain timing values for different operations.

I completely understand why it's frustrating or confusing by itself, though.

by Aurornis

1/1/2026 at 6:35:55 PM

Going to write a real banger of a paper called "latency numbers considered harmful is all you need" and watch my academic cred go through the roof.

by shanemhansen

1/1/2026 at 10:02:45 PM

" ... with an Application to the Entscheidungsproblem"

by AnonymousPlanet

1/1/2026 at 5:10:47 PM

Every Python programmer should be thinking about far more important things than low level performance minutiae. Great reference but practically irrelevant except in rare cases where optimization is warranted. If your workload grows to the point where this stuff actually matters, great! Until then it’s a distraction.

by willseth

1/1/2026 at 6:31:19 PM

Having general knowledge about the tools you're working with is not a distraction, it's an intellectual enrichment in any case, and can be a valuable asset in specific cases.

by HendrikHensen

1/1/2026 at 6:51:04 PM

Knowing that an empty string is 41 bytes or how many ns it takes to do arithmetic operations is not general knowledge.

by willseth

1/1/2026 at 7:40:59 PM

How is it not general knowledge? How do you otherwise gauge if your program is taking a reasonable amount of time, and, if not, how do you figure out how to fix it?

by oivey

1/2/2026 at 1:48:23 AM

In my experience, which is series A or earlier data intensive SaaS, you can gauge whether a program is taking a reasonable amount of time just by running it and using your common sense.

P50 latency for a fastapi service’s endpoint is 30+ seconds. Your ingestion pipeline, which has a data ops person on your team waiting for it to complete, takes more than one business day to run.

Your program is obviously unacceptable. And, your problems are most likely completely unrelated to these heuristics. You either have an inefficient algorithm or more likely you are using the wrong tool (ex OLTP for OLAP) or the right tool the wrong way (bad relational modeling or an outdated LLM model).

If you are interested in shaving off milliseconds in this context then you are wasting your time on the wrong thing.

All that being said, I’m sure that there’s a very good reason to know this stuff in the context of some other domains, organizations, company size/moment. I suspect these metrics are irrelevant to disproportionately more people reading this.

At any rate, for those of us who like to learn, I still found this valuable but by no means common knowledge

by dirtbag__dad

1/2/2026 at 2:26:09 AM

I'm not sure it's common knowledge, but it is general knowledge. Not all HNers are writing web apps. Many may be writing truly compute bound applications.

In my experience writing computer vision software, people really struggle with the common sense of how fast computers really are. Some knowledge like how many nanoseconds an add takes can be very illuminating to understand whether their algorithm's runtime makes any sense. That may push loose the bit of common sense that their algorithm is somehow wrong. Often I see people fail to put bounds on their expectations. Numbers like these help set those bounds.

by oivey

1/2/2026 at 12:15:32 PM

Thanks this is helpful framing!

by dirtbag__dad

1/1/2026 at 8:32:33 PM

You gauge with metrics and profiles, if necessary, and address as needed. You don’t scrutinize every line of code over whether it’s “reasonable” in advance instead of doing things that actually move the needle.

by willseth

1/1/2026 at 8:41:40 PM

These are the metrics underneath it all. Profiles tell you what parts are slow relative to others and time your specific implementation. How long should it take to sum together a million integers?

by oivey

1/1/2026 at 9:09:32 PM

It literally doesn’t matter unless it impacts users. I don’t know why you would waste time on non problems.

by willseth

1/1/2026 at 10:39:11 PM

No one is suggesting “wasting time on non problems.” You’re tilting at windmills.

by oivey

1/2/2026 at 12:10:01 AM

Read more carefully

by willseth

1/1/2026 at 8:46:16 PM

But these performance numbers are meaningless without some sort of standard comparison case. So if you measure that e.g. some string operation takes 100ns, how do you compare against the numbers given here? Any difference could be due to PC, python version or your implementation. So you have to do proper benchmarking anyway.

by cycomanic

1/2/2026 at 3:06:54 AM

If your program does 1 million adds, but it takes significantly longer than 19 milliseconds, you can guess that something else is going on.

by ehaliewicz2

1/1/2026 at 5:14:49 PM

Yeah, if you hit limits just look for a module that implements the thing in C (or write it). This is how it was always done in Python.

by amelius

1/1/2026 at 7:51:05 PM

I am currently (as we type actually LOL) doing this exact thing in a hobby GIS project: Python got me a prototype and proof of concept, but now that I am scaling the data processing to worldwide, it is obviously too slow so I'm rewriting it (with LLM assistance) in C. The huge benefit of Python is that I have a known working (but slow) "reference implementation" to test against. So I know the C version works when it produces identical output. If I had a known-good Python version of past C, C++, Rust, etc. projects I worked on, it would have been most beneficial when it came time to test and verify.

by ryandrake

1/2/2026 at 6:50:21 PM

I rather have a JIT that avoids the "rewrite in C", unless there is no way around it, after heroic optimizations.

by pjmlp

1/1/2026 at 5:35:37 PM

Sometimes it’s as simple as finding the hotspot with a profiler and making a simple change to an algorithm or data structure, just like you would do in any language. The amount of handwringing people do about building systems with Python is silly.

by willseth

1/1/2026 at 5:37:45 PM

I agree - however, that has mostly been a feeling for me for years. Things feel fast enough and fine.

This page is a nice reminder of the fact, with numbers. For a while, at least, I will Know, instead of just feel, like I can ignore the low level performance minutiae.

by kc0bfv

1/1/2026 at 7:01:18 PM 

   > Strings
   >The rule of thumb for strings is the core string object takes 41 bytes. Each       additional character is 1 byte.
That's misleading. There are three types of strings in Python (1, 2 and 4 bytes per character).

https://rushter.com/blog/python-strings-and-memory/

by f311a

1/1/2026 at 4:45:17 PM

The titles are oddly worded. For example -

  Collection Access and Iteration
  How fast can you get data out of Python’s built-in collections? Here is a dramatic example of how much faster the correct data structure is. item in set or item in dict is 200x faster than item in list for just 1,000 items!
It seems to suggest an iteration for x in mylist is 200x slower than for x in myset. It’s the membership test that is much slower. Not the iteration. (Also for x in mydict is an iteration over keys not values, and so isn’t what we think of as an iteration on a dict’s ‘data’).

Also the overall title “Python Numbers Every Programmer Should Know” starts with 20 numbers that are merely interesting.

That all said, the formatting is nice and engaging.

by riazrizvi

1/1/2026 at 9:41:34 PM

I liked reading through it from a "is modern Python doing anything obviously wrong?" perspective, but strongly disagree anyone should "know" these numbers. There's like 5-10 primitives in there that everyone should know rough timings for; the rest should be derived with big-O algorithm and data structure knowledge.

by robertclaus

1/1/2026 at 8:47:08 PM

It’s missing the time taken to instantiate a class.

I remember refactoring some code to improve readability, then observing something that was previously a few microseconds take tens of seconds.

The original code created a large list of lists. Each child list had 4 fields each field was a different thing, some were ints and one was a string.

I created a new class with the names of each field and helper methods to process the data. The new code created a list of instances of my class. Downstream consumers of the list could look at the class to see what data they were getting. Modern Python developers would use a data class for this.

The new code was very slow. I’d love it if the author measured the time taken to instantiate a class.

by sjducb

1/1/2026 at 10:43:02 PM

Instantiating classes is in general not a performance issue in Python. Your issue here strongly sounds like you're abusing OO to pass a list of instances into every method and downstream call (not just the usual reference to self, the instance at hand). Don't do that, it shouldn't be necessary. It sounds like you're trying to get a poor-man's imitation of classmethods, without identifying and refactoring whatever it is that methods might need to access from other instances.

Please post your code snippet on StackOverflow ([python] tag) or CodeReview.SE so people can help you fix it.

> created a new class with the names of each field and helper methods to process the data. The new code created a list of instances of my class. Downstream consumers of the list could look at the class to see what data they were getting.

by smcin

1/1/2026 at 8:53:24 PM

I went to the doctor and I said “It hurts when I do this”

The doctor said, “don’t do that”.

Edit: so yeah a rather snarky reply. Sorry. But it’s worth asking why we want to use classes and objects everywhere. Alan Kay is well known for saying object orientated is about message passing (mostly by Erlang people).

A list of lists (where each list is four different types repeated) seems a fine data structure, which can be operated on by external functions, and serialised pretty easily. Turning it into classes and objects might not be a useful refactoring, I would certainly want to learn more before giving the go ahead.

by lifeisstillgood

1/2/2026 at 6:57:05 AM

The main reason why is to keep a handle on complexity.

When you’re in a project with a few million lines of code and 10 years of history it can get confusing.

Your data will have been handled by many different functions before it gets to you. If you do this with raw lists then the code gets very confusing. In one data structure customer name might be [4] and another structure might have it in [9]. Worse someone adds a new field in [5] then when two lists get concatenated name moves to [10] in downstream code which consumes the concatenated lists.

by sjducb

1/1/2026 at 11:12:40 PM

I mean it sounds reasonable to me to wrap the data into objects.

customers[3][4]

is a lot less readable than

customers[3].balance

by krior

1/1/2026 at 11:46:45 PM

Absolutely

But hidden in this is the failing of every sql-bridge ever - it’s definitely easier for a programmer to read customers(3).balance but the trade off now is I have to provide class based semantics for all operations - and that tends to hide (oh you know, impedance mismatch).

I would far prefer “store the records as plain as we can” and add on functions to operate over it (think pandas stores basically just ints floats and strings as it is numpy underneath)

(Yes you can store pyobjects somehow but the performance drops off a cliff.)

Anyway - keep the storage and data structure as raw and simple as possible and write functions to run over it. And move to pandas or SQLite pretty quickly :-)

by lifeisstillgood

1/2/2026 at 3:43:57 PM

customers[3]['balance'] seems like a reasonable middle ground, no?

by fragmede

1/3/2026 at 11:39:14 AM

It depends - most likely that’s storing as a language specific data structure (dict in python then serialised to disk). At this point we’re walking into harder to turn around decisions and might as well do it properly. It still really “it depends” …

by lifeisstillgood

1/1/2026 at 7:59:39 PM

> small int (0-256) cached

It's -5 to 256, and these have very tricky behavior for programmers that confuse identity and equality.

  >>> a = -5
  >>> b = -5
  >>> a is b
  True
  >>> a = -6
  >>> b = -6
  >>> a is b
  False

by perrygeo

1/2/2026 at 12:39:33 AM

Java does similar. Confusing for beginners who run into it for the first time for sure.

by Tostino

1/2/2026 at 3:44:45 PM

wat

by fragmede

1/1/2026 at 5:47:30 PM

That's a long list of numbers that seem oddly specific. Apart from learning that f-strings are way faster than the alternatives, and certain other comparisons, I'm not sure what I would use this for day-to-day.

After skimming over all of them, it seems like most "simple" operations take on the order of 20ns. I will leave with that rule of thumb in mind.

by boerseth

1/1/2026 at 9:23:57 PM

If you're interested, fstrings are faster because they directly become bytecode at compile time rather than being a function call at runtime

by aunderscored

1/1/2026 at 10:47:14 PM

Thanks for the that bit of info! I was surprised by the speed difference. I have always assumed that most variations of basic string formatting would compile to the same bytecode.

I usually prefer classic %-formatting for readability when the arguments are longer and f-strings when the arguments are shorter. Knowing there is a material performance difference at scale, might shift the balance in favour of f-strings for some situations.

by apelapan

1/1/2026 at 6:09:03 PM

That number isn't very useful either, it really depends on the hardware. Most virtualized server CPUs where e.g. Django will run on in the end are nowhere near the author's M4 Pro.

Last time I benchmarked a VPS it was about the performance of an Ivy Bridge generation laptop.

by 0x000xca0xfe

1/1/2026 at 6:57:16 PM

> Last time I benchmarked a VPS it was about the performance of an Ivy Bridge generation laptop.

I have a number of Intel N95 systems around the house for various things. I've found them to be a pretty accurate analog for small instances VPSes. The N95 are Intel E-cores which are effectively Sandy Bridge/Ivy Bridge cores.

Stuff can fly on my MacBook but than drag on a small VPS instance but validating against an N95 (I already have) is helpful. YMMV.

by giantrobot

1/1/2026 at 4:39:29 PM

Python programmers don't need to know 85 different obscure performance numbers. Better to really understand ~7 general system performance numbers.

by xnx

1/1/2026 at 5:56:28 PM

Author here.

Thanks for the feedback everyone. I appreciate your posting it @woodenchair and @aurornis for pointing out the intent of the article.

The idea of the article is NOT to suggest you should shave 0.5ns off by choosing some dramatically different algorithm or that you really need to optimize the heck out of everything.

In fact, I think a lot of what the numbers show is that over thinking the optimizations often isn't worth it (e.g. caching len(coll) into a variable rather than calling it over and over is less useful that it might seem conceptually).

Just write clean Python code. So much of it is way faster than you might have thought.

My goal was only to create a reference to what various operations cost to have a mental model.

by mikeckennedy

1/1/2026 at 7:05:37 PM

Then you should have written that. Instead you have given more fodder for the premature optimization crowd.

by willseth

1/1/2026 at 10:21:46 PM

I didn't tell anyone to optimize anything. I just posted numbers. It's not my fault some people are wired that way. Anytime I suggested some sort of recommendation it was to NOT optimize.

For example, from the post "Maybe we don’t have to optimize it out of the test condition on a while loop looping 100 times after all."

by mikeckennedy

1/2/2026 at 3:53:24 AM

The literal title is "Python Numbers Every Programmer Should Know" which implies the level of detail in the article (down to the values of the numbers) is important. It is not.

It is helpful to know the relative value (costs) of these operations. Everything else can be profiled and optimized for the particular needs of a workflow in a specific architecture.

To use an analogy, turbine designers no longer need to know the values in the "steam tables", but they do need to know efficient geometries and trade-offs among them when designing any Rankine cycle to meet power, torque, and Reynolds regimes.

by calmbonsai

1/1/2026 at 4:28:03 PM

Nice numbers and it's always worth to know an order of magnitude. But these charts are far away from what "every programmer should know".

by ktpsns

1/1/2026 at 4:46:20 PM

I think we can safely steelman the claim to "every Python programmer should know", and even from there, every "serious" Python programmer, writing Python professionally for some "important" reason, not just everyone who picks up Python for some scripting task. Obviously there's not much reason for a C# programmer to go try to memorize all these numbers.

Though IMHO it suffices just to know that "Python is 40-50x slower than C and is bad at using multiple CPUs" is not just some sort of anti-Python propaganda from haters, but a fairly reasonable engineering estimate. If you know that you don't really need that chart. If your task can tolerate that sort of performance, you're fine; if not, figure out early how you are going to solve that problem, be it through the several ways of binding faster code to Python, using PyPy, or by not using Python in the first place, whatever is appropriate for your use case.

by jerf

1/1/2026 at 5:16:48 PM

This is really weird thing to worry about in python. But is also misleading; Python int is arbitrary precision, they can take up much more storage and arithmetic time depending in their value.

by ZiiS

1/2/2026 at 12:00:30 AM

The one I noticed the most was import openai and import numpy.

They're both about a full second on my old laptop.

I ended up writing my own simple LLM library just so I wouldn't have to import OpenAI anymore for my interactive scripts.

(It's just some wrapper functions around the equivalent of a curl request, which is honestly basically everything I used the OpenAI library for anyway.)

by andai

1/2/2026 at 11:00:54 AM

I have noticed how long it takes to import numpy. It made rerunning a script noticably sluggish. Not sure what openai's excuse is, but I assume numpy's slowness is loading some native dlls?

by kristianp

1/3/2026 at 1:27:58 PM

OpenAI I haven't used in years but originally it would import many heavy libraries like I believe scikit-learn, and iirc they only used it for the cosine similarity formula for their embeddings function (lol).

by andai

1/1/2026 at 9:15:45 PM

You absolutely do not need to know those absolute numbers--only the relative costs of various operations.

Additionally, regardless of the code you can profile the system to determine where the "hot spots" are and refactor or call-out to more performant (Rust, Go, C) run-times for those workflows where necessary.

by calmbonsai

1/2/2026 at 3:08:16 AM

Great catalogue. On the topic of msgspec, since pydantic is included it may be worth including a bench for de-serializing and serializing from a msgspec struct.

by cma256

1/1/2026 at 4:35:26 PM

I doubt list and string concatenation operate in constant time, or else they affect another benchmark. E.g., you can concatenate two lists in the same time, regardless of their size, but at the cost of slower access to the second one (or both).

More contentiously: don't fret too much over performance in Python. It's a slow language (except for some external libraries, but that's not the point of the OP).

by tgv

1/1/2026 at 4:41:03 PM

String concatenation is mentioned twice on that page, with the same time given. The first time it has a parenthetical "(small)", the second time doesn't have it. I expect you were looking at the second one when you typed that as I would agree that you can't just label it as a constant time, but they do seem to have meant concatenating "small" strings, where the overhead of Python's object construction would dominate the cost of the construction of the combined string.

by jerf

1/1/2026 at 9:38:29 PM

Interesting information but these are not hard numbers.

Surely the 100-char string information of 141 bytes is not correct as it would only apply to ASCII 100-char strings.

It would be more useful to know the overhead for unicode strings presumably utf-8 encoded. And again I would presume 100-Emoji string would take 441 bytes (just a hypothesis) and 100-umlaut chars string would take 241bytes.

by sireat

1/3/2026 at 12:57:53 PM

The goal of the article is not to know the exact numbers by heart, duh!

Care about orders of magnitude instead, in combination with the speed of hardware https://gist.github.com/jboner/2841832 you'll have a good understanding of how much overhead is due to the language and the constructs to favor for speed improvements.

Just reading the code should give you a sense of its speed and where it will spend most time. Combined with general timing metrics you can also have a sense of the overhead of 3rd party libraries (pydantic I'm looking at you).

So yeah, I find that list quite useful during the code design, likely reduce time profiling slow code in prod.

by HenriTEL

1/1/2026 at 10:13:41 PM

There are lots of discussions about relatedness of these numbers for a regular software engineer.

Firstly, I want to start with the fact that the base system is a macOS/M4Pro, hence;

- Memory related access is possibly much faster than a x86 server. - Disk access is possibly much slower than a x86 server.

*) I took x86 server as the basis as most of the applications run on x86 Linux boxes nowadays, although a good amount of fingerprint is also on other ARM CPUs.

Although it probably does not change the memory footprint much, the libraries loaded and their architecture (ie. being Rosetta or not) will change the overall footprint of the process.

As it was mentioned on one of the sibling comments -> Always inspect/trace your own workflow/performance before making assumptions. It all depends on specific use-cases for higher-level performance optimizations.

by pvtmert

1/1/2026 at 5:08:12 PM

What would be the explanation for an int taking 28 bytes but a list of 1000 ints taking only 7.87KB?

by jchmbrln

1/1/2026 at 6:16:54 PM

That appears to be the size of the list itself, not including the objects it contains: 8 bytes per entry for the object pointer, and a kilo-to-kibi conversion. All Python values are "boxed", which is probably a more important thing for a Python programmer to know than most of these numbers.

The list of floats is larger, despite also being simply an array of 1000 8-byte pointers. I assume that it's because the int array is constructed from a range(), which has a __len__(), and therefore the list is allocated to exactly the required size; but the float array is constructed from a generator expression and is presumably dynamically grown as the generator runs and has a bit of free space at the end.

by wiml

1/1/2026 at 7:37:54 PM

That's impressive how you figured out the reason for the difference in list of floats vs list of ints container size, framed as an interview question that would have been quite difficult I think

by lopuhin

1/1/2026 at 7:19:56 PM

It was. I updated the results to include the contained elements. I also updated the float list creation to match the int list creation.

by mikeckennedy

1/1/2026 at 11:16:19 PM

Surprised that list comprehensions are only 26% faster than for loops. It used to feel like 4-5x

by charlieyu1

1/1/2026 at 4:42:56 PM

It's important to know that these numbers will vary based on what you're measuring, your hardware architecture, and how your particular Python binary was built.

For example, my M4 Max running Python 3.14.2 from Homebrew (built, not poured) takes 19.73MB of RAM to launch the REPL (running `python3` at a prompt).

The same Python version launched on the same system with a single invocation for `time.sleep()`[1] takes 11.70MB.

My Intel Mac running Python 3.14.2 from Homebrew (poured) takes 37.22MB of RAM to launch the REPL and 9.48MB for `time.sleep`.

My number for "how much memory it's using" comes from running `ps auxw | grep python`, taking the value of the resident set size (RSS column), and dividing by 1,024.

1: python3 -c 'from time import sleep; sleep(100)'

by oogali

1/2/2026 at 6:23:08 PM

Knowing all of these is exactly what a developer shouldn't need to do. Fix "big O" problems in your own code. And be aware of a few exceptionally weird counterintuitive things if it matters on a "big O" level — like "you think this common operation is O(1) but it's actually O(N^2)". If there actually are any of those. And just get stuff done.

I guess you could find yourself in a situation where a 2X speedup is make or break and you're not a week away from needing 4X, etc. But not very often.

by boutell

1/1/2026 at 10:08:53 PM

I'm confused by this:

  String operations in Python are fast as well. f-strings are the fastest formatting style, while even the slowest style is still measured in just nano-seconds.
  
  Concatenation (+)   39.1 ns (25.6M ops/sec)
  f-string            64.9 ns (15.4M ops/sec)
It says f-strings are fastest but the numbers show concatenation taking less time? I thought it might be a typo but the bars on the graph reflect this too?

by CmdrKrool

1/2/2026 at 11:05:40 AM

Perhaps it's because in all but the simplest cases, you need 2 or more concatenations to achieve the same result as one single f-string?

  "literal1 " + str(expression) + " literal2"
vs

  f"literal1 {expression} literal2"
The only case that would be faster is something like: "foo" + str(expression)

by Liquid_Fire

1/2/2026 at 1:18:07 PM

String concatenation isn't usually considered a "formatting style", that refers to the other three rows of the table which use a template string and have specialized syntax inside it to format the values.

by Izkata

1/2/2026 at 2:14:10 AM

It is always a good idea to have at least a rough understanding of how much operations in your code cost, but sometimes very expensive mistakes end up in non-obvious places.

If I have only plain Python installed and a .py file that I want to test, then what's the easiest way to get a visualization of the call tree (or something similar) and the computational cost of each item?

by mopsi

1/1/2026 at 7:35:03 PM

Hmmmm, there should absolutely be standard deviations for this type of work. Also, what is N number of runs? Does it say somewhere?

by belabartok39

1/1/2026 at 9:23:42 PM

It is open source, you could just look. :) But here is a summary for you. It's not just one run and take the number:

Benchmark Iteration Process

Core Approach:

- Warmup Phase: 100 iterations to prepare the operation (default)

- Timing Runs: 5 repeated runs (default), each executing the operation a specified number of times

- Result: Median time per operation across the 5 runs

Iteration Counts by Operation Speed: - Very fast ops (arithmetic): 100,000 iterations per run

- Fast ops (dict/list access): 10,000 iterations per run

- Medium ops (list membership): 1,000 iterations per run

- Slower ops (database, file I/O): 1,000-5,000 iterations per run

Quality Controls:

- Garbage collection is disabled during timing to prevent interference

- Warmup runs prevent cold-start bias

- Median of 5 runs reduces noise from outliers

- Results are captured to prevent compiler optimization elimination

Total Executions: For a typical benchmark with 1,000 iterations and 5 repeats, each operation runs 5,100 times (100 warmup + 5×1,000 timed) before reporting the median result.

by mikeckennedy

1/1/2026 at 9:50:00 PM

That answers what N is (why not just say in the article). If you are only going to report medians, is there an appendix with further statistics such as confidence intervals or standard deviations. For serious benchmark, it would be essential to show the spread or variability, no?

by belabartok39

1/1/2026 at 8:15:07 PM

The point of the original list was that the numbers were simple enough to memorize: https://gist.github.com/jboner/2841832

Nobody is going to remember any of the numbers on this new list.

by esafak

1/1/2026 at 10:20:16 PM

That's a fair point @esafak. I updated the article with something akin to the doubling chart of numbers in the original article from 2012.

by mikeckennedy

1/1/2026 at 4:43:26 PM

Initially I thought how efficient strings are... but then I understood how inefficient arithmetic is. Interesting comparison but exact speed and IO depend on a lot of things, and unlikely one uses Mac mini in production so these numbers definitely aren't representative.

by dr_kretyn

1/1/2026 at 11:56:28 PM

As someone who most often works in a language that is literally orders of magnitude slower than this —- and has done so since CPU speeds were measured in double-digit megahertz —- I am crying at the notion that anything here is measured in nanoseconds

by gcanyon

1/1/2026 at 5:41:56 PM

Why? If those micro benchmarks mattered in your domain, you wouldn't be using python.

by mwkaufma

1/1/2026 at 5:52:42 PM

That's an "all or nothing" fallacy. Just because you use Python and are OK with some slowdown, doesn't mean you're OK with each and every slowdown when you can do better.

To use a trivial example, using a set instead of a list to check membership is a very basic replacement, and can dramatically improve your running time in Python. Just because you use Python doesn't mean anything goes regarding performance.

by coldtea

1/1/2026 at 6:12:14 PM

That's an example of an algorithmic improvement (log n vs n), not a micro benchmark, Mr. Fallacy.

by mwkaufma

1/1/2026 at 10:18:39 PM

"Mr. Fallacy."? Got any better juvenile name-calling?

The case is among the example numbers given in TFA:

"Dict lookup by key", "List membership check"

Does it have to spell out the difference is algorithmic in this case for the comparison to be useful?

Or, inversely, is the difference between e.g. memory and disk access times insignificant, because it's not algorithmic?

by coldtea

1/1/2026 at 7:41:58 PM

...and other hilarious jokes you can tell yourself!

by PhilipRoman

1/2/2026 at 10:21:06 AM

I'm surprised that the `isinstance()` comparison is with `type() == type` and not `type() is type`, which I would expect to be faster, since the `==` implementation tends to have an `isinstance` call anyway.

by superlopuh

1/2/2026 at 10:22:16 AM

Also seems like the repo is now private, so I can't open an issue, or reproduce the numbers.

by superlopuh

1/1/2026 at 9:57:11 PM

I think a lot of commenters here are missing the point.

Looking at performance numbers is important regardless if it's python, assembly or HDL. If you don't understand why your code is slow you can always look at how many cycles things take and learn to understand how code works at a deeper level, as you mature as a programmer things will become obvious, but going through the learning process and having references like these will help you to get there sooner, seeing the performance numbers and asking why some things take much longer—or sometimes why they take the exact same time—is the perfect opportunity to learn.

Early in my python career I had a python script that found duplicate files across my disks, the first iteration of the script was extremely slow, optimizing the script went through several iterations as I learned how to optimize at various levels. None of them required me to use C. I just used caching, learned to enumerate all files on disk fast, and used sets instead of lists. The end result was that doing subsequent runs made my script run in 10 seconds instead of 15 minutes. Maybe implementing in C would make it run in 1 second, but if I had just assumed my script was slow because of python then I would've spent hours doing it in C only to go from 15 minutes to 14 minutes and 51 seconds.

There's an argument to be made that it would be useful to see C numbers next to the python ones, but for the same reason people don't just tell you to just use an FPGA instead of using C, it's also rude to say python is the wrong tool when often it isn't.

by nodja

1/1/2026 at 4:31:46 PM

Great reference overall, but some of these will diverge in practice: 141 bytes for a 100 char string won’t hold for non-ASCII strings for example, and will change if/when the object header overhead changes.

by woodruffw

1/1/2026 at 9:21:45 PM

One of the reasons I'm really excited about JAX is that I hope it will allow me to write fast Python code without worrying about these details.

by JBits

1/1/2026 at 7:52:59 PM

I'm confused why they repeatedly call a slots class larger than a regular dict class, but don't count the size of the dict

by lunixbochs

1/1/2026 at 6:20:13 PM

> Numbers are surprisingly large in Python

Makes me wonder if the cpython devs have ever considered v8-like NaN-boxing or pointer stuffing.

by Retr0id

1/1/2026 at 4:52:59 PM

int is larger than float, but list of floats is larger than list of ints

Then again, if you're worried about any of the numbers in this article maybe you shouldn't be using Python at all. I joke, but please do at least use Numba or Numpy so you aren't paying huge overheads for making an object of every little datum.

by Y_Y

1/2/2026 at 1:14:04 AM

My god, the memory bloat is out of this world compared to platforms like the JVM or .NET, let alone C++ or Rust!

by jiggawatts

1/2/2026 at 6:35:09 PM

Great resource. I would also like to see a comparison of variable access times across different scopes.

by intalentive

1/1/2026 at 11:23:30 PM

> Attribute read (obj.x) 14 ns

note that protobuf attributes are 20-50x worse than this

by Redoubts

1/2/2026 at 12:53:21 AM

I wonder why an empty set takes so much more memory than an empty dict

by rozab

1/1/2026 at 7:22:02 PM

+1 but I didn't see pack / unpack...

by m3047

1/1/2026 at 7:39:31 PM

LLMs can improve Python code performance. I used it myself on a few projects.

by lcnmrn

1/2/2026 at 3:03:41 AM

Exactly wrong.

by iamnotsure

1/1/2026 at 7:11:48 PM

I have some questions and requests for clarification/suspicious behavior I noticed after reviewing the results and the benchmark code, specifically:

- If slotted attribute reads and regular attribute reads are the same latency, I suspect that either the regular class may not have enough "bells on" (inheritance/metaprogramming/dunder overriding/etc) to defeat simple optimizations that cache away attribute access, thus making it equivalent in speed to slotted classes. I know that over time slotting will become less of a performance boost, but--and this is just my intuition and I may well be wrong--I don't get the impression that we're there yet.

- Similarly "read from @property" seems suspiciously fast to me. Even with descriptor-protocol awareness in the class lookup cache, the overhead of calling a method seems surprisingly similar to the overhead of accessing a field. That might be explained away by the fact that property descriptors' "get" methods are guaranteed to be the simplest and easiest to optimize of all call forms (bound method, guaranteed to never be any parameters), and so the overhead of setting up the stack/frame/args may be substantially minimized...but that would only be true if the property's method body was "return 1" or something very fast. The properties tested for these benchmarks, though, are looking up other fields on the class, so I'd expect them to be a lot slower than field access, not just a little slower (https://github.com/mikeckennedy/python-numbers-everyone-shou...).

- On the topic of "access fields of objects" (properties/dataclasses/slots/MRO/etc.), benchmarks are really hard to interpret--not just these benchmarks, all of them I've seen. That's because there are fundamentally two operations involved: resolving a field to something that produces data for it, and then accessing the data. For example, a @property is in a class's method cache, so resolving "instance.propname" is done at the speed of the methcache. That might be faster than accessing "instance.attribute" (a field, not a @property or other descriptor), depending on the inheritance geometry in play, slots, __getattr[ibute]__ overrides, and so on. On the other hand, accessing the data at "instance.propname" is going to be a lot more expensive for most @properties (because they need to call a function, use an argument stack, and usually perform other attribute lookups/call other functions/manipulate locals, etc); accessing data at "instance.attribute" is going to be fast and constant-time--one or two pointer-chases away at most.

- Nitty: why's pickling under file I/O? Those benchmarks aren't timing pickle functions that perform IO, they're benchmarking the ser/de functionality and thus should be grouped with json/pydantic/friends above.

- Asyncio's no spring chicken, but I think a lot of the benchmarks listed tell a worse story than necessary, because they don't distinguish between coroutines, Tasks, and Futures. Coroutines are cheap to have and call, but Tasks and Futures have a little more overhead when they're used (even fast CFutures) and a lot more overhead to construct since they need a lot more data resources than just a generator function (which is kinda what a raw coroutine desugars to, but that's not as true as most people think it is...another story for another time). Now, "run_until_complete{}" and "gather()" initially take their arguments and coerce them into Tasks/Futures--that detection, coercion, and construction takes time and consumes a lot of overhead. That's good to know (since many people are paying that coercion tax unknowingly), but it muddies the boundary between "overhead of waiting for an asyncio operation to complete" and "overhead of starting an asyncio operation". Either calling the lower-level functions that run_until_complete()/gather() use internally, or else separating out benchmarks into ones that pass Futures/Tasks/regular coroutines might be appropriate.

- Benchmarking "asyncio.sleep(0)" as a means of determining the bare-minimum await time of a Python event loop is a bad idea. sleep(0) is very special (more details here: https://news.ycombinator.com/item?id=46056895) and not representative. To benchmark "time it takes for the event loop to spin once and produce a result"/the python equivalent of process.nextTick, it'd be better to use low-level loop methods like "call_soon" or defer completion to a Task and await that.

by zbentley

1/1/2026 at 5:09:40 PM

tfa mentions running benchmark on a multi-core platform, but doesn't mention if benchmark results used multithreading.. a brief look at the code suggests not

by 867-5309

1/1/2026 at 4:51:43 PM

Yeah... No. I've 10+ years of python under my belt and I might have had need for this kind of micro optimizations in like 2 times most

by _ZeD_

1/1/2026 at 7:19:47 PM

Sorry, you’re not allowed to discourage premature optimization or defend Python here.

by willseth

1/1/2026 at 6:08:49 PM

This is AI slop.

by ewuhic

1/2/2026 at 11:04:37 AM

Sad that your comment is downvoted. But yes, for those who need clarification:

1) Measurements are faulty. List of 1,000 ints can be 4x smaller. Most time measurements depend on circumstances that are not mentioned, therefore can't be reproduced.

2) Brainrot AI style. Hashmap is not "200x faster than list!", that's not how complexity works.

3) orjson/ujson are faulty, which is one of the reasons they don't replace stdlib implementation. Expect crashes, broken jsons, anything from them

4) What actually will be used in number-crunching applications - numpy or similar libraries - is not even mentioned.

by Lockal

1/7/2026 at 8:01:47 AM

> Add two integers 19.0 ns (52.7M ops/sec)

Your computer is slow. /s

by hulitu