[Patches] [ python-Patches-868736 ] Add GC collection to timeit

[SourceForge.net]

Patches item #868736, was opened at 2004-01-01 03:54
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add GC collection to timeit

Initial Comment:
This patch adds a gc.collect() before each timing.

Since timings are only relevant when compared to other
timings, it makes sense to put them on as equal footing
as possible.  Running a gc.collect() before each timing
provides some assurance that a routine gc collection
won't throw-off one timing while not affecting another.

At worst, this patch does nothing.  At best, it makes
the timings more comparable.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-03 22:49

Message:
Logged In: YES 
user_id=80475

Applied Tim's more conservative approach to Lib/timeit.py 1.16.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 12:23

Message:
Logged In: YES 
user_id=80475

Blowing the cache is desirable because it puts each timing
on the same footing.  Note, the gc.collect() goes before the
%setup statements which will leave their data in the cache,
and the inner loop quickly establishes its own cache access
pattern.  IOW, the cache will only contain information
relevant to the test and not reflect the state of the system
just prior to the test.

Trying it out a few times shows more consistent timings (or
it could just be my imagination).  I have a suite of timings
for the set module, and even with this patch, the timings
still show some sensitivity to the order the tests are run.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-01 11:48

Message:
Logged In: YES 
user_id=31435

Nope, gc is no longer optional.

It may (or may not ...) be better to disable gc than to run it 
in this context, as running gc will blow the cache (by chasing 
every container object, and at least visiting every contained 
object, in existence).  That effect is much worse than just 
letting gc run naturally (forcing collection chews through all 
generations; letting it run naturally usually just looks at the 
youngest generation).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-01-01 11:17

Message:
Logged In: YES 
user_id=6380

Good idea.

(I don't remember -- is it still possible to build Python
without gc? If it is, the gc import and use should be
conditional. But I vaguely remember it's no longer optional.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470