How bad can Python stop-the-world pauses get?

class Node:
    def __init__(self, value):
        self.value = value
        self.next = None
    def add_next(self, node):
        self.next = node

def create_linked_list(limit):
    """ create a linked list of length 'limit' """
    head = Node(0)
    current = head
    for i in range(1, limit):
        new_node = Node(i)
        current.add_next(new_node)
        current = new_node
    return head

x = create_linked_list(50_000_000)
for i in range(1000000):
    create_linked_list(1000)

8 thoughts on “How bad can Python stop-the-world pauses get?”

1. I am interested in how “bad” the Stop-The-World pauses get if you were to compare it against the latest Python 3.14t, which is the “free-threaded” or “no-GIL” build of the Python 3.14 interpreter. Thank you, Dr. Lemire!

   Reply

2. Instagram got a 10% speed up on their Django setup by disabling GC but it’s not because the GC itself is slow. It had some post-fork memory access patterns that wasted resources. Their writeup is here:

   https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172

   Reply

3. I’m being pedantic, but I can’t resist pointing out that Python-the-programming-language does not require reference counting. It’s CPython, the official reference implementation, that uses reference counting + garbage collection, but popular alternative implementations like PyPy and Jython use garbage collection only, and the Python language spec allows this.

   This is actually an annoying source of incompatibility between implementations. For example, a loop like this:

   for _ in range(1000000): open(‘/dev/null’)

   will run just fine in CPython, but PyPy (usually) crashes with “Too many open files”. The reason is that the open file object, which is never closed explicitly in this example, is closed implicitly when it is garbage collected. With CPython, this deterministically happens after the open call returns, since the result is not assigned anywhere. With PyPy, garbage collection is deferred until memory is low, and systems usually run out of file descriptors long before they run out of memory, which causes the error.

   The correct solution is not to rely on garbage collection to release resources other than heap memory, and always close files and other resource objects explicitly. The with-statement is useful to do this robustly, but beginning programmers often forget to use it, or don’t understand the need for it.

   If it was up to me, I’d at least print a warning whenever an open file is garbage collected, since this is clearly a logic error. I don’t know why Python implementations don’t do this; perhaps they are afraid this will print too many spurious warnings for one-off scripts, where it’s arguably okay to open a handful of files that are never explicitly closed.

   Reply

   1. Thanks. I point out that, in the post, I wrote “The common Python implementation has both types (…)”. I consider CPython to be the common Python implementation.

      Reply

4. I use reference counting only in the interpreter I wrote. There the answer to using circular data is (1) Don’t do it, and (2) If you do it, break the cycle yourself before abandoning the data.

   Reply

5. Interesting… I don’t understand why the GC is involved at all, since the program produces no circular references…

   Here’s what I thought would happen: After the call create_linked_list(1000) returns, the return value is discarded, which means its reference count goes to zero, so it is deallocated and the count of its outgoing reference is decremented, and so on, until the 1000 nodes have been deallocated. And I expected that all of this happens before execution actually returns to the main loop.

   That should deallocate all 1000 nodes before the next iteration, memory should never run low, and each iteration should take pretty much the same amount of time.

   In other words, I thought the whole reference counting machinery uses an eager approach: as soon as we find a zero counter, clear all references from this object, decrement their counters, check for zero, and so on recursively.

   What am I missing? Does CPython delay some of the reference counting and deallocation until later? Or does a separate GC thread do the job? Interesting…

   Reply

   1. In other words, I thought the whole reference counting machinery uses an eager approach: as soon as we find a zero counter, clear all references from this object, decrement their counters, check for zero, and so on recursively.

      Yes. I believe this is what happens.

      But the generational garbage collector still runs periodically.

      To be clear, the generational garbage collector is useless in my case, but it does not know that it is useless. So it has to do its work.

      Reply

   2. I definitely do an eager drop in my reference counting code:

      https://github.com/chkoreff/Fexl/blob/master/src/value.c#L53

      I did experiment with a lazy drop which simply queues up cells with refcount 0. It worked fine, but there’s always a possibility that large unused strings will get buried in the queue and never reclaimed on demand because new cells are constantly getting pushed on top of it. I played with methods of “nudging” the recycle queue so that all cells eventually get visited, but the whole thing just seemed needlessly complex so I went back to the eager approach. The eager approach was faster anyway.

      I know this isn’t directly related to Python, but your question reminded me of my experience with reference counting implementations.

      Reply

You can also subscribe by email to this blog (non-commercial, no ads, weekly email).

How to post code (C, C++, Java, Python, etc.):

Wrap your code in backticks, like this:

`int main() {
    return 0;
}`