I have a program which calls filecmp.cmp a lot.It runs out of memory.I read the source to filecmp, and then I periodically setfilecmp._cache = {}Without doing this, filecmp's cache uses up all the memory in the computer.There needs to be a documented interface to clear the cache.I suggest a functiondef clear_cache:    _cache = {}Without a documented interface, there is no standard way to clear thecache. It is possible different versions of python will requiredifferent methods to clear the cache, which will reduce python codeportability and is a bad idea.Alternatively, one might disable the caching code.One shouldn't have to look at the source code of a library functionto see why it is consuming memory.

I've looked at the code for Python 3, and there isn't anything there thatprevents this from happening there, either. So the fix should be appliedto 3.2 and 3.3 as well.An alternative approach would be to limit the size of the cache, so thatthe caller doesn't need to explicitly clear the cache. Something alongthe lines of functools.lru_cache() should do the trick. I don't thinkit'll be possible to use lru_cache() itself, though - it doesn't providea mechanism to invalidate cache entries when they become stale (and inany case, it doesn't exist in 2.7).

Putting in a size limit is reasonable.  We did this for fnmatch not that long ago (issue 7846).  That was in fact the inspiration for lru_cache.

Patch for 3.3 and 3.2

Patch for 2.7.

Oops, there was a typo in the 2.7 patch ("import _thread" instead of"import thread"). Corrected patch attached.

Why use an ordered dict instead of functools.lru_cache?

Because the lru_cache decorator doesn't provide any way to invalidatestale cache entries.Perhaps I should factor out the duplicated code into a separate classthat can then also be exposed to users of the stdlib. But that would onlyapply to 3.3, so the uglier fix is still necessary for older versions.

I question whether this should be backported.  Please discuss with the RM.

> I question whether this should be backported.  Please discuss with the RM.Will do. Are you referring specifically to 2.7, or to 3.1 and 3.2 as well?

Georg? Benjamin? Do you think this fix should be backported?

-1 on backporting.

OK. I'll try to put together something cleaner just for 3.3, then.

Nadeem, I want to review this but won't have a chance to do it right away.  Offhand, it seems like we could use the existing functools.lru_cache() for this if the stats were included as part of the key:  cache[f1, f2, s1, s2]=outcome.Also, I want to take a fresh look at the cache strategy (saving diffs of two files vs saving file contents individually) and think about whether than makes any sense at all for real world use cases (is there a common need to compare the same file pairs over and over again or is the typical use the comparison of many different file pairs).   There may even be a better way to approach the underlying problem using hashes of entire files (md5, sha1, etc).

There are many possible solutions to this problem.Personally, I think mine is the simplest, though it changes the API.However, there have been several suggestions on simple fixes that don't change the API, all of which fix the resource leak.Doing nothing will not fix the resource leak.How about a simple fix right now, using a lru cache, fixing all versions of Python, and perhaps come up with a superior solution at a later date?

We will do something.  The next release isn't for a while, so there is time to put thought into it rather than making an immediate check-in.

> Also, I want to take a fresh look at the cache strategy (saving diffs> of two files vs saving file contents individually) and think about> whether than makes any sense at all for real world use cases> (is there a common need to compare the same file pairs over and over> again or is the typical use the comparison of many different file> pairs).   There may even be a better way to approach the underlying> problem using hashes of entire files (md5, sha1, etc).I like that idea. A hash-based approach could speed up the detection ofnon-equal files quite a bit.

New changeset11568c59d9d4 by Raymond Hettinger in branch '2.7':Issue 11802:  filecmp cache was growing without bound.http://hg.python.org/cpython/rev/11568c59d9d4

New changeset2bacaf6a80c4 by Raymond Hettinger in branch '3.2':Issue 11802:  filecmp cache was growing without bound.http://hg.python.org/cpython/rev/2bacaf6a80c4New changeset8f4466619e1c by Raymond Hettinger in branch 'default':Issue 11802:  filecmp cache was growing without bound.http://hg.python.org/cpython/rev/8f4466619e1c

Made a simple fix to keep the cache from growing without bound.Leaving this open for 3.3 as a feature request to implement a more sophisticated strategy using file hashes or somesuch.

After more thought, will just close this report.  If a new project emerges to improve the design of filecmp, it can be done in a separate tracker entry.