Hacker News Reader

Comment by genjipress | Hacker News Reader

I'd be curious to see if any of the work done here could be applied back to the main CPython project. I doubt it could happen immediately -- at least, not with the way GC is currently implemented -- but PyPy has been a source of innovation for CPython in the past (see: new dict implementation).

View on HN

CPython already has a lower latency GC than PyPy, gc.disable() already works, and allowed manual memory management when needed.

Reference counting allows you (if needed) to keep references to memory in your python code, and free them in the right spots.

This is PyPy becoming useful for a lot more production use cases. From web APIs that have a latency SLA, to audio, games. In many cases peak performance is not important, it's the minimum performance.

Refcounting comes with its own in-thread gc pauses whenever you exit a block or context and the local variables are collected.

Yeah. However you have the option to not pause if it is important. You can control where the memory management happens. You can either keep references to the memory, and call gc.disable(). When you are ready you can let go the references and enable the gc.

PyPy now lets you control where memory management happens. Making it possible to control worst case performance. For many production apps this is a big deal.

You can never prevent the GC cycle in CPython at the end of a block (context). You can only prevent the GC that tries to break reference cycles. If your class does crazy things at destruction, like "time.sleep(10)", and you create an instance of the class inside a function, when that function returns you will pause CPython even if you call gc.disable()

You also cannot disable the minor collections in PyPy, only the major collections, but once the JIT kicks in PyPy can prevent some of the object churn by optimizing instances away.

Yeah. Avoiding slow things like classes, threads and adding time.sleep(10) is the trick.

Reply on news.ycombinator.com