Refcounting comes with its own in-thread gc pauses whenever you exit a block or context and the local variables are collected.
Re:PyPy for low-latency systems
by throwaway12iii on Friday January 04, 2019 @01:20AM
(#18822332)
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.
Re:PyPy for low-latency systems
by throwaway12iii on Friday January 04, 2019 @06:51AM
(#18823371)
Yeah. Avoiding slow things like classes, threads and adding time.sleep(10) is the trick.
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.