Performance hacks for faster Python code
blog.jetbrains.com
Performance hacks for faster Python code
1–10 of 65 posts
Re: Performance hacks for faster Python code
#2Re: Performance hacks for faster Python code
#3I think maybe a more realistic example there would be people using splatting without realizing/internalizing that it performs a full copy, e.g.
xs = [1, *ys]
Another one that stood out was (3). Slots are great, but >95% of the time I'd expect people would want to use `slots=True` with dataclasses instead of manually writing `__slots__` and a constructor like that. `slots=True` has worked since Python 3.10, so every non-EOL version of Python supports it.Re: Performance hacks for faster Python code
#4(2) surprised me a little. Not because of the performance consequences, but because I almost never see explicit calls to `copy()` in Python (and I read a lot of Python). I think maybe a more realistic example there would be people using splatting without realizing/internalizing that it performs a full copy, e.g. xs = [1, *ys] Another one that stood out was (3). Slots are great, but >95% of the time I'd expect people…
Re: Performance hacks for faster Python code
#5(2) surprised me a little. Not because of the performance consequences, but because I almost never see explicit calls to `copy()` in Python (and I read a lot of Python). I think maybe a more realistic example there would be people using splatting without realizing/internalizing that it performs a full copy, e.g. xs = [1, *ys] Another one that stood out was (3). Slots are great, but >95% of the time I'd expect people…
You can use __slots__ for normal classes; it’s not limited to only dataclasses.
Re: Performance hacks for faster Python code
#6Re: Performance hacks for faster Python code
#7In general I feel like these kind of benchmarks might change for each python version, so some caveats might apply.
Re: Performance hacks for faster Python code
#8Re: Performance hacks for faster Python code
#9> modify[ing] objects in place […] improves performance by avoiding the overhead of allocating and populating new structures.
AFAIK the poor performance of list copies (demonstrated in the article by a million-element list taking 10ms) doesn’t come from memory allocation nor from copying the contents of the list itself (in this case, a million pointers).
Rather it comes from the need to chase all of those pointers, accessing a million disparate memory locations, in order to increment each element’s reference count.
Re: Performance hacks for faster Python code
#10Maybe also knowing when not to use python, or finding a solution in python that uses C/rust/etc underneath.