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.

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.

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

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.

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.

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.

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