From c62b95e550a521760e9b9495bbd4f31ac4a15eb0 Mon Sep 17 00:00:00 2001 From: Tim Peters Date: Thu, 11 Jul 2002 19:07:45 +0000 Subject: test_trashcan() and supporting class Ouch(): Jeremy noted that this test takes much longer to run in the context of the test suite than when run in isolation. That's because it forces a large number of full collections, which take time proportional to the total number of gc'ed objects in the whole system. But since the dangerous implementation trickery that caused this test to fail in 2.0, 2.1 and 2.2 doesn't exist in 2.3 anymore (the trashcan mechanism stopped doing evil things when the possibility for compiling without cyclic gc was taken away), such an expensive test is no longer justified. This checkin leaves the test intact, but fiddles the constants to reduce the runtime by about a factor of 5. --- Lib/test/test_gc.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Lib/test/test_gc.py b/Lib/test/test_gc.py index 751206a..977f7b0 100644 --- a/Lib/test/test_gc.py +++ b/Lib/test/test_gc.py @@ -181,7 +181,7 @@ class Ouch: n = 0 def __del__(self): Ouch.n = Ouch.n + 1 - if Ouch.n % 7 == 0: + if Ouch.n % 17 == 0: gc.collect() def test_trashcan(): @@ -192,9 +192,15 @@ def test_trashcan(): # If this test fails (as it does in 2.0, 2.1 and 2.2), it will # most likely die via segfault. + # Note: In 2.3 the possibility for compiling without cyclic gc was + # removed, and that in turn allows the trashcan mechanism to work + # via much simpler means (e.g., it never abuses the type pointer or + # refcount fields anymore). Since it's much less likely to cause a + # problem now, the various constants in this expensive (we force a lot + # of full collections) test are cut back from the 2.2 version. gc.enable() - N = 200 - for count in range(3): + N = 150 + for count in range(2): t = [] for i in range(N): t = [t, Ouch()] -- cgit v0.12