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.
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?
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.
My first thought was that pixels are never square. Squares are an artifact of nearest sampling to another grid. I suppose pixel art assumes knowledge of this final grid, but most media doesn’t?
Furthermore, the referencing of a raster can assume any shape or form. It makes some sense some signals are optimized for hardware restrictions.
Another interesting example are anamorphic lenses used in cinema.
I wouldn't call advanced movement "speeding up Quake". Speed in Quake and other FPS is an important factor that influences what you based on the speed that you have. Bunny hopping, air control, rocket jumps are not as useful when the base speed goes up. Also, less maneuverability, like in Quake 2, and bigger maps, mean that you have to be more judicious about your next move, and plan ahead more, stock up on more items, etc. There is an important balance to these things.
Anytime this topic comes up, I ask: Why not both? I don't want to modify my SQL strings every time I change a column. Django ORM lets me combine custom SQL snippets with ORM code. I never hesitate to use custom SQL, but its just not a reasonable default for basic CRUD operations that my IDE can autocomplete. Not only that, but also provide nice feautures pike named arguments, walking relationships, sanitizations, etc. At the same time, I can do a UNIONS, CTES, anything I want. I just don't understand why it's worth arguing against ORMs, when no one is forcing you to stop using raw SQL.
I completely agree, it is absolutely essential to understand what SQL is emitted, and how SQL works. Perhaps the strawman argument against ORMs is that they preclude you from knowing SQL. They don't.
I don’t see splashes of primary color as more artistic. Anyway, what if you just ask it “more coarse”? I see impressive depth in the latest outputs, but as with all technically proficient performers, you might just have to consciously scale it back.