On Mon, Apr 29, 2002, Barry A. Warsaw wrote: > > Isn't this a case of "knowing your application"? IOW, you're doing > something that the gc isn't well-tuned to handle, by default. That's > why we expose the its operation through the gc module -- so you can > take explicit steps for the hotspots in your application. > > Not to say we can't improve the tuning, but it'll never be perfect, so > just try to make it good enough for the most common types of > programs. Then document situations where it might not do so well. My take is that programs with a million live objects and no cycles are common enough that gc should be designed to handle that smoothly. I don't think that a programmer casually writing such applications (say, processing information from a database) should be expected to understand gc well enough to tune it. Having read the entire discussion so far, and *NOT* being any kind of gc expert, I would say that Tim's adaptive solution makes the most sense to me. For years, we told people with cyclic data to figure out how to fix the problem themselves; now that we have gc available, I don't think we should punish everyone else. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "I used to have a .sig but I found it impossible to please everyone..." --SFJ
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