[Python-Dev] A "new" kind of leak

Tim Peters tim.one@comcast.net
Sat, 13 Apr 2002 01:48:15 -0400

FYI, I plugged the leak in 2.2 and current CVS via bounding the frameobject
free_list.  I skipped 2.1 (lots of cyclic stuff leaks there; somebody can
tell me to work on that, but I'm not volunteering).

I think it took about 4x longer than it would have *just* to fix it in the
head.  This surprised me.  In retrospect, though, it doesn't:  obviously,
there's twice as much of everything (twice as many checkins to do, twice as
many files to edit, twice as many tests to run, etc), and there's no
"economy of scale".  But it's worse than just that, because there are
endless little costs switching between them, and especially on Windows where
I use a GUI to build (and have to poke around finding the right project file
to load), and changing directories in a DOS box is clumsy, and I also wanted
an additional Cygwin shell to try to apply a patch, generated on the trunk,
to the 2.2 branch.  Trying to switch among all these things while the
time-consuming parts are running, in different parts of the process on
different branches, quickly leads to mistakes, and then there's extra time
to recover from those.  There's also an urge to try to copy collateral text
(checkin notes, NEWS) from one branch to the other, and so more little files
get created to effect the transfer.

So it goes -- I didn't think we'd get twice the fixes for free <wink>.  This
was a small bugfix, and so the overheads swamped the time spent just fixing
the code.  For a larger bugfix I'd expect more like a factor of 3 oerall --
unless the code can't be backported mechanically, in which case it may take
arbitrarily longer.

predicting-your-future-ly y'rs  - tim