[Python-Dev] Lazily GC tracking tuples
Thu, 30 May 2002 09:20:08 -0400 (EDT)
On Tue, 28 May 2002, Tim Peters wrote:
> [Kevin Jacobs, on Neil's tuple-untracking patch]
> > It doesn't seem to make much difference in our app. There seems
> > to be some speedup, but nothing dramatic. Turning GC on and off at the
> > right times is still slightly faster.
> I'm confused. You earlier said:
> I've found one case where the garbage collector _does_ cause
> serious performance problems, and coincidentally enough it is due to
> the creation of zillions of cycle-less tuples. Our current solution
> has been to disable GC in some parts of our code, and then manually
> trigger collection at the correct points.
> Now I'm hearing that turning GC on and off is only "slightly faster", and
> that the speedup is so small you're not even sure there is one ("turning GC
> on and off" is "slightly faster" than a trial where there "seems to be some
> speedup"). This is not "serious performance problems" except to nanosecond
> counters like me <wink>.
Sorry, I wasn't very clear here. The patch _does_ fix the performance
problem by untracking cycle-less tuples when we use the naive version of our
code (i.e., the one that does not play with the garbage collector).
However, the performance of the patched GC when compared to our GC-tuned
code is very similar.
> > The good news is that another (unrelated) part of our code just became
> > about 20-40% faster with this patch, though I need to do some fairly
> > major surgery to isolate why this is so.
> Keep us informed! I suspect you're suffering from an app that's more than
> 20 lines long; I try to stay away from those.
Try 20Kloc for this one. Our unit tests tend to be too fine-grained to
detect these kinds of interactions, so it may be a while before I isolate
exactly why this is.
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: firstname.lastname@example.org
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com