6 runs two division operations in the ”unoptimized” version and one in the ”optimized” version. Gee, I wonder why it’s exactly twice faster.
Performance hacks for faster Python code
51–60 of 65 posts
Re: Performance hacks for faster Python code
#52Re: Performance hacks for faster Python code
#53a smart hack for performance is don't use python
Exactly. Consider rewriting the hot paths to a C extension, or using cython or nim. Pypy or the jit rarely
Re: Performance hacks for faster Python code
#54Isn't this pretty obvious if you spent more than three weeks writing python? There are lots tricks, but these listed here seem relevant to all languages. There is an almost an incountable amount of ways to write bad and slow python code that are not as obvious.
I remember the day I realized how much I dislike python. I have never had it click for me, despite writing it in and off since the python 2.0. There are always some new arbitrary places for it to bite you, and it always feels a little yucky. And then one day I saw something like this:
# b is not defined here
if blahblah():
b = gronk()
# might raise an exception
do_stuff(b)
Edit: and maybe someone can explain to me why anyone would make it so that the simplest way to iterate through a collection is not the fastest? This is the case for most languages, but it still feels dumb. Just allow a slightly more obtuse syntax like
for a in b
Re: Performance hacks for faster Python code
#55Isn't this pretty obvious if you spent more than three weeks writing python? There are lots tricks, but these listed here seem relevant to all languages. There is an almost an incountable amount of ways to write bad and slow python code that are not as obvious. I remember the day I realized how much I dislike python. I have never had it click for me, despite writing it in and off since the python 2.0. There are alway…
Hack #2 seems counter to the functional way of doing things.
The hack for using Math instead of operators seems dumb.
Re: Performance hacks for faster Python code
#56Isn't this pretty obvious if you spent more than three weeks writing python? There are lots tricks, but these listed here seem relevant to all languages. There is an almost an incountable amount of ways to write bad and slow python code that are not as obvious. I remember the day I realized how much I dislike python. I have never had it click for me, despite writing it in and off since the python 2.0. There are alway…
Try as I might, I can't get that to raise an exception.
That said, agreed that this is weird. Python makes some really unintuitive choices regarding scope.
Re: Performance hacks for faster Python code
#57Isn't this pretty obvious if you spent more than three weeks writing python? There are lots tricks, but these listed here seem relevant to all languages. There is an almost an incountable amount of ways to write bad and slow python code that are not as obvious. I remember the day I realized how much I dislike python. I have never had it click for me, despite writing it in and off since the python 2.0. There are alway…
Try as I might, I can't get that to raise an exception. That said, agreed that this is weird. Python makes some really unintuitive choices regarding scope.
it raises an exception if blahblah() returns False, because then b never gets defined.
Re: Performance hacks for faster Python code
#58Isn't this pretty obvious if you spent more than three weeks writing python? There are lots tricks, but these listed here seem relevant to all languages. There is an almost an incountable amount of ways to write bad and slow python code that are not as obvious. I remember the day I realized how much I dislike python. I have never had it click for me, despite writing it in and off since the python 2.0. There are alway…
Try as I might, I can't get that to raise an exception. That said, agreed that this is weird. Python makes some really unintuitive choices regarding scope.
Ok. Try this.
if input() == "dynamic scope?":
defined = "happyhappy"
print(defined)Re: Performance hacks for faster Python code
#59Maybe also knowing when not to use python, or finding a solution in python that uses C/rust/etc underneath.
It's kinda funny how uv is written in Rust and many Python libraries where performance is expected to matter (NumPy, Pandas, PyTorch, re, etc.) are implemented in C. Even if you call into fast code from Python you still have to contend with the GIL which I find very limiting for anything resembling performance.
GIL is on its way out - https://peps.python.org/pep-0703/
Re: Performance hacks for faster Python code
#60Earlier quoted context omitted.
swap with last element then truncate at the end
Yes, you can do this if you don't care about order, and avoid the performance degradation. But it's even more complex. Or if you do care about order, you can emulate the C++ "erase-remove" idiom, by keeping track of separate "read" and "write" positions in the source, iterating until "read" reaches the end, and only incrementing "write" for elements that are kept; and then doing a single `del` of a slice at the end.…
You can do the in place variant using generator comprehension and writing the result in place in the original vector. The generator should run ahead of the write and should work fine.
It will also probably be significantly slower than just copying the vector.