Talk - Anthony Shaw: Write faster Python! Common performance anti patterns

This talk will show small, specific examples of Python code that can be refactored to be faster without compromising on readability. At the start of the talk, I'll explain how to set up a profiler to measure application performance and how to track improvements and regressions.

[@SuperGrimmy]

It's amazing what you learn over time when hyper-optimizing python code. We've been optimizing the python arcade library a lot over the last two years managing in some cases to boost speed by 10x in certain locations just with pure python. One example that shocked me is how slow weak references or containers for weak references like weak sets are. Using that as a container for sprites was 4-5x slower than a plain list. Also dataclasses was a trap for us. When you have 10-16ms per frame, every tiny things really starts to matter. The function call overhead is not a joke. Even things like a @property can slow down things.

[@_elkd]

Thanks Anthony for the talk and benchmarking with Pypy as well. I run Pypy where I can, my biggest fear with microoptimizing is that sometimes you gain performance with CPython but then Pypy comes along with surprises. The best part of this talk is that in all 4 cases CPython is happy and so is Pypy. But when you start to replace builtins, do some C level twerks, it appears Pypy just love naive Python code.

[@ZuLuuuuuu]

Great talk. The point Anthony mentioned about profiling your code to discover the exact places where your code slows down is very important. I frequently see people trying to optimize insignificant parts of their code just because they _guessed_ what was slowing down their code, instead of profiling it. Also, it is important to ask yourself if you really need to optimize your code, you might be surprised that sometimes simple and theoretically inefficient implementations can be fast enough.

[@juliejones8785]

It would be nice to see what kind of tests that you ran to compare performance of Tuple, Dataclass and class. I was surprised at your results and wonder if typical usage would be inline with your tests.

[@stephenaustin3026]

CPython Internals is a very good book. But it would be a GREAT BOOK if only it had an index.

[@AnthonyShaw]

Thanks! And I will ask Dan again about getting an index.

[@minyakonga8897]

what i learned: before optimizing your code, you need a comparison, thus each time you optimize, run the comparison and check if it speeds up.

[@louismaddox6151]

wait I want some socks

[@cat-.-]

First anti pattern I want you all to remember: instead giving files name ending in .py, you should end it with .c

[@Tutez]

why?