I’ve also seen order of magnitude improvements going from both C and Java to Python (in the latter case also a similar reduction in memory consumption). It’s certainly true that CPython should be faster but I think we’re prone as a field to focusing on the cool compiler/language level Real Programming™ problems rather than dwelling on how inefficiently most programs are designed to be. The language matters, of course, but it also takes a certain humility to say we picked the wrong abstractions or spent time on the wrong parts, or that our expectations were shaped by microbenchmarks unlike the code we actually write.
I’ve lost track of how many times someone jumped to “ZOMG THE GIL SUCKS!!!!” but the real lesson turned out to be something like “maybe I shouldn’t open files in the middle of a nested loop”[1] or “the C extension used for dict/re/Numpy/etc. is actually pretty hard to beat”. One big problem for comparisons is that most of the time people don’t do a straight rewrite but change the algorithm based on the experience they got writing the first version - my Python beating C examples all fell into that category where it was really a refactor nobody wanted to do in a gnarled C codebase, or simply didn’t have time to make in a more limited language.
1. Someone I know ranted about Python, spent a month rage-porting to Go, and saw ~10% over the improved Python version.
For microbenchmarks, yes. My comment was referring to a lot of the folk knowledge derived from porting larger applications where people attribute gains to a new language which incorporate significant architectural changes as well.
I don’t think anyone is downvoting you for saying Python is slow. You were downvoted because it’s not a substantive comment. You’re replying to a title instead of engaging with the contents of the article, and even then it adds nothing to the discussion since “that slow” isn’t well defined, anyone could say “yup” or “nope” to any imagined value of “that”.
