Comment 17 for bug 956979

On 03/19/2012 09:09 AM, Martin Sandve Alnæs wrote:
> On 19 March 2012 07:47, Johan Hake<email address hidden> wrote:
>> On 03/18/2012 11:56 PM, Kristian B. Ølgaard wrote:
>>> On 16 March 2012 16:56, Johan Hake<email address hidden>
>>> wrote:
>>>> On Mar 16, 2012 4:35 PM, "Garth Wells"<email address hidden>
>>>> wrote:
>>>>>
>>>>> On 16 March 2012 15:17, Anders Logg<email address hidden> wrote:
>>>>>> On Fri, Mar 16, 2012 at 03:04:14PM -0000, Martin Sandve Alnæs
>>>>>> wrote:
>>>>>>> On 16 March 2012 15:49, Johan Hake<email address hidden>
>>>>>>> wrote:
>>>>>>>> This is really a duplication of bug 897372, which compared
>>>>>>>> FFc and
>>>> SFC,
>>>>>>>> as SFC compiles the attached form just fine. The generated
>>>>>>>> code is
>>>> much
>>>>>>>> smaller. Talking with Martin, I get the impression that FFC
>>>>>>>> does not
>>>> use
>>>>>>>> the information UFL provides about the internal structure
>>>>>>>> of the different sub expressions. I got the impression that
>>>>>>>> FFC lump the
>>>> whole
>>>>>>>> expression into a large string.
>>>>>>>
>>>>>>> ... for arguments to MathFunctions that is, according to
>>>>>>> earlier comments from Kristian.
>>>>>>>
>>>>>>> Material models for biological tissue often have rather
>>>>>>> complex arguments to e.g. exp.
>>>>>>>
>>>>>
>>>>> Which explode when linearised.
>>>>
>>>> Sure, but not that bad. SFC managed just fine. FFC optimization
>>>> might help.
>>>>
>>>> FYI both SFC and FFC still use heck of alot memory. This might be
>>>> rooted in the repr are which grow quite large during a compile. Not
>>>> sure how to profile memory use in python...
>>>
>>> For speed, objects are cached in FFC (and I believe also in SFC the
>>> last time I checked) so as the expression become more and more
>>> complex the memory usage will increase. The simplify_expression
>>> optimisation strategy for FFC is particular poor in this regard as it
>>> relies on first expanding the expression before trying to optimise it
>>> which results in a lot of temporary expressions (objects) being
>>> created.
>>
>> What algorithm are you talking about that stores all these temporary
>> objects. I have at least found out that the memory explosion happens within:
>>
>> ffc:extract_monomial_integrand
>>
>> within the call to
>>
>> ufl:purge_list_tensors
>>
>> Which indicates that UFL is actually the leaker her. This also makes
>> sense as SFC show the same huge memory usage.
>
> Not quite, because SFC never calls that function...

The culprit isn't that function but rather the one that
purge_list_tensors calls

   expand_indices

which is reported in the filed UFL bug.

Johan

>> Will file a speate bug to UFL for this.
>
> Please do, I can take a look at the UFL side.
>
> Martin
>