Cyclops 0.9.4
Tim Peters
tim_one at email.msn.com
Tue Jul 20 02:31:49 EDT 1999
More information about the Python-list mailing list
Tue Jul 20 02:31:49 EDT 1999
- Previous message (by thread): Cyclops 0.9.4
- Next message (by thread): Cyclops 0.9.4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[nascheme at ucalgary.ca] > [This message has also been posted.] Ditto. > Cool. How about a feature that displays only cycles created > since a marking function was called. I think this would be most > useful in programs that leak memory. You don't care if cycles > exist, you just don't want them to be continually created. The > way I see this working is you start up something like IDLE, do > some stuff, call the marking function, do more stuff, call cycle > showing function. You can do this yourself by installing a cycle filter, that returns false whenever it sees a cycle that's been seen before. I don't think it could be done more efficiently than that if implemented inside Cyclops, although Cyclops knows how to subtract its internal references from the refcounts delivered via get_rootset(). A user-written cycle filter can do that too for its own references, but it is a little tricky to get straight. Simpler, just call find_cycles() followed by show_stats() from time to time. One of the output lines is "# cycles found: <n>". New cycles are being found if & only if n is increasing. Now if you actually *try* any of these and find them helpful in "real life", pass it on! My experience in IDLE was that cycles weren't actually causing the leaks, although up until it hit a dead end they were correlated with leaks; the real cause was references in basic (reachable) objects that weren't getting cleared out when the widgets they referenced got closed. enough-to-make-you-dizzy-ly y'rs - tim
- Previous message (by thread): Cyclops 0.9.4
- Next message (by thread): Cyclops 0.9.4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list