Performance hacks for faster Python code

https://blog.jetbrains.com/pycharm/2025/11/10-smart-performance-hacks-for-faster-python-code/

by ashvardanian • 8 months ago

119 64 8 months ago

blog.jetbrains.com

tyingq2• 8 months ago

Maybe also knowing when not to use python, or finding a solution in python that uses C/rust/etc underneath.

knowitnone32• 8 months ago

maybe you can skip C and just use assembly

guhcampos• 8 months ago

Or fab your own chip.

tyingq2• 8 months ago

If it's a module doing cryptography, maybe...Not suggesting C or rust in places where it doesn't make sense. Python itself make choices about whether the things it ships with are pure python or not. They often are not.

lunias7• 8 months ago

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.

woodruffw5• 8 months ago

Python's strong native story has always been one of its biggest draws: people find it ironic that so much of the Python ecosystem is native code, but it plays to Python's strength (native code where performance matters, Python for developer joy/ergonomics/velocity).

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.

It depends. A lot of native extension code can run without the GIL; the normal trick is to "detach" from the GIL for critical sections and only reconnect to it once Python needs to see your work. PyO3 has a nice collection of APIs for holding/releasing the GIL and for detaching from it entirely[1].

[1] https://docs.rs/pyo3/0.27.1/pyo3/marker/struct.Python.html#m...

zahlman6• 8 months ago

In my analysis, the lion's share of uv's performance improvement over pip is not due to being written in Rust. Pip just has horrible internal architecture that can't be readily fixed because of all the legacy cruft.

And for numerical stuff it's absolutely possible to completely trash performance by naively assuming that C/Rust/Fortran etc. will magically improve everything. I saw an example in a talk once where it superficially seemed obvious that the Rust code would implement a much more efficient (IIRC) binary search (at any rate, some sub-linear algorithm on an array), but making the data available to Rust; as a native Rust data structure, required O(N) serialization work.

vovavili• 8 months ago

GIL is on its way out - https://peps.python.org/pep-0703/

fainpul• 8 months ago

People are making fun of this statement here / are being sarcastic. But it's a totally legit suggestion. If you know in advance, you are going to make something where performance matters, strongly consider using something other than one of the slowest languages of them all.

woodruffw5• 8 months ago

(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 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.

sgarland• 8 months ago

You can use __slots__ for normal classes; it’s not limited to only dataclasses.

woodruffw5• 8 months ago

I know that; that's why I said "I'd expect" not "you can't."

jessetemp• 8 months ago

I didn't find 2 surprising either, but I'm a little surprised you never see it. If you want to treat the args to a function as immutable, what can you do besides copy, modify, and return a new object?

zahlman6• 8 months ago

what can you do besides copy, modify, and return a new object?

You can directly produce a modified copy, rather than using a mutating operation to implement the modifications.

It should be noted that "return a modified copy" algorithms can be much more efficient than "mutate the existing data" ones. For example, consider the case of removing multiple elements from a list, specified by a predicate. The version of this code that treats the input as immutable, producing a modified copy, can perform a single pass:

  def without(source, predicate):
      return [e for e in source if not predicate(e)]

whereas mutating code can easily end up with quadratic runtime — and also be difficult to get right:

  def remove_which(source, predicate):
      i = 0
      while i < len(source):
          if predicate(source[i]):
              # Each deletion requires O(n) elements to shift position.
              del source[i]
          else:
              # The index increment must be conditional,
              # since removing an element shifts the next one
              # and that shifted element must also be considered.
              i += 1

woodruffw5• 8 months ago

I think copying and modifying is normal! I just almost never see it with `copy()`. Apologies if I didn't say that clearly.

automatoney• 8 months ago

There's some genuinely interesting tips in here, but #10 is for sure just padding so they could call the article "10 Hacks" haha. Everything else is at least somewhat Python specific, but "Hack 10: Avoid repeated function calls in loops" is just applicable to anything.

knowitnone32• 8 months ago

I agree. I can't imagine anybody would call a function that returns the same result in a loop like that. There are plenty more optimizations they could come up with. In fact, there are a couple of books https://www.oreilly.com/library/view/high-performance-python... for instance. Didn't want to link the one on Amazon

FuckButtons• 8 months ago

Yeah, 10 felt like it was written by ai.

zahlman6• 8 months ago

A lot of it felt that way, to me.

persedes• 8 months ago

Some helpful guidelines, but it's 2025 and people still use time.time and no stats with their benchmarks :(

In general I feel like these kind of benchmarks might change for each python version, so some caveats might apply.

igouy• 8 months ago

Perhaps you could suggest what should be used instead of time.time

zem• 8 months ago

https://switowski.com/blog/how-to-benchmark-python-code/ has a decent overview of some benchmarking libraries

LigmaBaulls• 8 months ago

a smart hack for performance is don't use python

rurban• 8 months ago

Exactly. Consider rewriting the hot paths to a C extension, or using cython or nim. Pypy or the jit rarely

pansa2• 8 months ago

Copying large objects like lists […] can be costly in both time and memory.
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.

trollbridge• 8 months ago

Yeah. A more nuanced approach is that you should copy things that don't consist of lots and lots of references to other things, and you should mutate things that are mostly references to other structures.

Which means, eventually, designing your data structures so you generally have two types of structures: one which isn't full of pointers, and one which mostly is.

lunias7• 8 months ago

What about using PyPy? You'll probably see a significant improvement in these benchmarks. You should also give it a shot in Node which I expect to be about on par with PyPy, but without the GIL.

danudey3• 8 months ago

If anyone wants to be surprised by optimization, a great way to do it is to look at all the cases where, even though Python is slower than C, the Python interpreter written in Python is faster than the Python interpreter written in C.

Also, if we're going to suggest 'write it in another language' approaches, rewrite it in Golang. I detest writing in Golang but once you get the hang of things you can get to the point where your code only takes twice the time to write and 2% of the time (and memory) to run.

lunias7• 8 months ago

rewrite it in Golang

Totally, I'm a big fan of statically typed, compiled languages; especially when the codebase is large and/or there are a lot of contributors. I chose the Node example because I feel like it offers the same "ease-of-use" that draws people to Python.

get to the point where your code only takes twice the time to write and 2% of the time (and memory) to run.

100%. Sometimes this matters, sometimes it doesn't, but if we're talking about "smart performance hacks" this is definitely a top contender.

I work on a Python project and I really wish that it supported multi-threading. If I rewrote it, I would prioritize that feature in the target language.

ecshafer• 8 months ago

1,2,5 are just kind of standard computer science knowledge things I would expect any CS2 student to know, and are pretty universal across most languages.

Some of these are pretty nice python tricks though.

qsort2• 8 months ago

I'm sure this is plenty useful for less experienced people, but the "smart" hacks read a bit like:

Hack 1: Don't Use The Obviously Wrong Data Structure For Your Problem!

Hack 2: Don't Have The Computer Do Useless Stuff!

Hack 3: Don't Allocate Memory When You Don't Need To!

And now, a word from our sponsor: AI! Use AI to help AI build AI with AI, now with 15% more AI! Only with AI! Ask your doctor if AI is right for you!

It's worth pointing out that a few of them are Python-specific. Compilers can inline code, there's usually no need to manually inline functions in most languages, that's Python being Python. Which scope the function is from being important is quintessentially Python being Python.

The major gains in Python come from... not using Python. Essentially you have to rewrite your code around the fact that numpy and pandas are the ones really doing the work behind the curtain (e.g. aggressively vectorize, use algorithms that can use vectorization well rather than "normal" ones). Number 8 of the list hints at that.

sevensor• 8 months ago

“Hacks” 4-10 could easily be replaced with “use numpy.” Performance gains from doing math better in pure Python are minimal compared with numpy. It’s not unusual for the numpy version of something to end up taking 0.01x as long to run.

fluorinerocket• 8 months ago

Yes I didn't realize anyone actually did anything numerical without numpy. I don't think I've ever imported python's math module once. Who in their right mind is making a 1e6 long python list

qsort2• 8 months ago

Math is a lost cause, yeah, just use numpy (with the important caveat that you need to know what you're doing, it's easy to fumble badly).

But Python has a few interesting features that can easily get you big wins, like generators, e.g. https://www.dabeaz.com/generators/Generators.pdf

prinzmaus• 8 months ago

Use polars vs pandas. This alone saves me more time than any other “hack”.

danudey3• 8 months ago

Not to mention that a lot of these performance improvements, while sane, are on the order of milliseconds of improvement. Unless you're doing one of these unoptimized approaches thousands or millions of times in a tight loop you're probably not saving a substantial amount of time/energy/computation. Premature optimization is still the root of all evil!

If you want an actual performance improvement in Python code that most people wouldn't necessarily expect: consider using regexes for even basic string parsing if you're doing a lot of it, rather than doing it yourself (e.g. splitting strings, then splitting those strings, etc.); while regexes "feel" like they should be more complicated and therefore slower or less efficient, the regex engine in Python is implemented in C and there's a decent chance that, with a little tweaking, even simple string processing can be done faster with a regex. Again only important in a hot loop, but still.

adammarples• 8 months ago

I remember learning not to use dot access in performance critical loops

nodesocket• 8 months ago

While obvious, a huge performance improvement bump can had using cachetools on functions. Cachetools is much more feature rich than lru_cache with support for TTL.

zahlman6• 8 months ago

A previous submission of this (https://news.ycombinator.com/item?id=45937910) didn't take off; I'm posting this to cite my comment there (https://news.ycombinator.com/item?id=45940360) rather than copying and pasting it.

yegle• 8 months ago

FWIW: the `x in foo` test calls the `foo.__contains__` magic method.

For a list, the only way to implement it is by iterate through it (see the `list_contains` function in the CPython code).

But for the special `range` object, it can implement the `__contains__` efficiently by looking at the start/stop/step (see the `range_contains` source code).

Although the Hack 1 is for demonstration purpose, in most cases you can just do `999999 in range(1000000)`.

In my test, the same `999999 in foo` is 59.1ns for the range object, 27.7ns for the set, 6.7ms for the list. The set is the fastest, except converting the range object to the set takes 21ms.

cluckindan• 8 months ago

6 runs two division operations in the ”unoptimized” version and one in the ”optimized” version. Gee, I wonder why it’s exactly twice faster.

bjoli2• 8 months ago

Isn'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)

That tingles in all the wrong places. Ruby has other issues, but the core is still feels elegant. I still prefer scheme, though.

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<list>

and make that case just as fast as doing it with a while loop. The iterator protocol is imho for when we frankly don't know/care what we are iterating over, or when we elwant to be generic, or when the data structure can't expose the most efficient way of doing it (like a tree). There is no reason why for a in b: should be slower than while when b is a list or string.

givemeethekeys• 8 months ago

Hack #2 seems counter to the functional way of doing things.

The hack for using Math instead of operators seems dumb.

rewgs• 8 months ago

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.

Doxin• 8 months ago

it raises an exception if blahblah() returns False, because then b never gets defined.

bjoli2• 8 months ago

Ok. Try this.

    if input() == "dynamic scope?":
        defined = "happyhappy"
    print(defined)

utbabya• 8 months ago

Most of the time I find the pros of not mutating variables out weight any potential memory / performance gain, of course it depends on what you're doing, but I find it rare other than perhaps scientific related code.

driggs• 8 months ago

Funny that Hack #1 compares list versus set value lookup, but the timer doesn't include the time to copy the list into a set. Hack #2 warns against unnecessary copying, and the time for copying the list is almost the same as the performance gain in Hack #1.

In fact, creating a set takes longer than copying a list since it requires hash insertion, so it's actually much faster to do the opposite of what they suggest for #1 (in the case of a single lookup, for this test case).

Here's the results with `big_set = set(big_list)` inside the timing block for the set case:

    List lookup: 0.013985s
    Set lookup:  0.052468s

godelski• 8 months ago

I'm surprised that this was not the first complaint. It's pretty clear "Hack" #1 isn't going to work.

  import random
  import time

  def timeit(func, _list, n=1000):
      start = time.time()
      for _ in range(n):
          func(_list=_list )
      end = time.time()
      print(f"Took {end-start} s")
      return

  def lstsearch(_list):
      sf = random.randint(0,len(_list))
      if sf in _list:
          return
      return

  def setsearch(_list):
      sf = random.randint(0, len(_list))
      if sf in set(_list):
          return
      return

  mylist = list(range(100000))

  timeit(lstsearch, mylist)
  timeit(setsearch, mylist)

  ----
  Took 0.23349690437316895 s
  Took 0.8901607990264893 s

mont_tag• 8 months ago

All good suggestions. However, the last one should have also mentioned functools.cache and functools.lru_cache.

Performance hacks for faster Python code

Related Stories