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 _______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
