> I took the statement, "Current GC only takes into account container > objects, which, most significantly, ignores string objects (of which > most applications create plenty)" to mean that strings were ignored for > deciding when to do garbage collection. I mistakenly thought that was > because they were assumed to be small. It sounds like they're ignored > because they're automatically collected and so they SHOULD be ignored > for object garbage collection. More precisely, a string object can never participate in a cycle (it can be referenced from a cycle, but not be *in* the cycle, as it has no references to other objects). GC in Python is only about container objects (which potentially can be cyclic); non-container objects are released when the refcount says they are no longer referenced. Whether or not allocation of definitely-non-cyclic objects should still trigger cyclic GC (in the hope that some objects hang on a garbage cycle) is a question that is open to debate; I'd prefer an analysis of existing applications before making decisions. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4