Comment 15 for bug 956979

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...

> Will file a speate bug to UFL for this.

Please do, I can take a look at the UFL side.

Martin