ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Feb 01, 2011 at 09:30:18AM -0000, Mikael Mortensen wrote:
> Public bug reported:
>
> The _memory_check in ffc/jitcompiler.py gets stuck at 10. In the code
>
> else:
>         preprocessed_form = preprocess(form, common_cell=common_cell)
>         _memory_cache[(id(form), repr(form))] = preprocessed_form
>
>         # For each 10th time the refcount of the cached form are checked
>         # and superflous forms are poped
>         if (_memory_check % 10) == 0:
>             for key, cached_form in _memory_cache.items():
>                 if sys.getrefcount(cached_form) < 6:
>                     _memory_cache.pop(key)
>         else:
>             _memory_check += 1
>
>
> if (_memory_check % 10) == 0 is True, then it doesn't add 1 and remains stuck at 10 meaning that it will check the whole _memory_cache on every new form.
>
> This particular piece of code is also responsible for some more
> headache. In my code I set up a large numer of forms (perhaps > 20) and
> solve my equations. No problems. I then decide to make some changes
> (perhaps to a model constant), which requires that I also redefine all
> my forms. When I continue with my iterations the refcount seams to be
> less than 6 and my new form always gets popped and iterations slows down
> because of the repeated Form call in assemble that never gets use of
> _memory_cache. Anyway, I hacked it for my equationset simply by using a
> larger value than 10 in the _memory_check above. Perhaps this should be
> a parameter?
>
> ** Affects: ffc
>      Importance: Undecided
>          Status: New

I'm not sure why we need to limit the memory cache at all. I don't
remember adding this particular code. Who added it?

--
Anders