71–80 of 221 posts
It’s a good article on speed. But honestly the thing that makes any of my programs slow is network calls. And there a nice async setup goes a long way. And then k8 for the scaling.
I didn't read with 100% focus, but this lwn account of the talk seemed to confirm those myths instead of debunking.
Yep, for me it confirms all the reasons why I think python is slow and not a good language for anything that goes beyond a script. I work with it everyday, and I have learned that I can't even trust tooling such as mypy because it's full of corner cases - turns out that not having a clear type design in a language is not something that can be fundamentally fixed by external tools. Tests are the only thing that can ma…
Yes, that is literally the explicit point of the talk. The first myth of the article was “python is not slow“
I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock. While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings. As…
I know I am going to get some hate for this from the "Python-stans" but..."python" and "performance" should never be associated with each other, and same for any scripting/interpreted programming language. Especially if it has a global interpreter lock. While performance (however you may mean that) is always a worthy goal, you may need to question your choice of language if you start hitting performance ceilings. As…
So we are paying 99% of the performance just for the 1% of cases where it's nice to code in. Why do people think it's a good trade-off?
Because many never used Smalltalk, Common Lisp, Self, Dylan,... so they think CPython is the only way there is, plus they already have their computer resources wasted by tons of Electron apps anyway, that they hardly question CPython's performance, or lack thereof.
Earlier quoted context omitted.
Isn't this just a specific example of the general rule of pulling out repeated use of the same operation in a loop? I'm not sure calls out to C are specifically slow in CPython (given many operations are really just calling C underneath).
The serialisation cost of translating data representations between python and C (or whatever compiled language you're using) is notable. Instead of having the compiled code sit in the centre of a hot loop, it's significantly better to have the loop in the compiled code and call it once https://pythonspeed.com/articles/python-extension-performanc...
The primary focus here is good and something I hadn't considered: python memory being so dynamic leads to poor cache locality. Makes sense. I will leave that to others to dig into. That aside, I was expecting some level of a pedantic argument, and wasn't disappointed by this one: "A compiler for C/C++/Rust could turn that kind of expression into three operations: load the value of x, multiply it by two, and then stor…
A “sufficiently smart compiler” can’t legally skip Python’s semantics. In Python, p.x * 2 means dynamic lookup, possible descriptors, big-int overflow checks, etc. A compiler can drop that only if it proves they don’t matter or speculates and adds guards—which is still overhead. That’s why Python is slower on scalar hot loops: not because it’s interpreted, but because its dynamic contract must be honored.
Somehow Smalltalk JIT compilers handle it without major issues.