Remove dynamic memory allocations in Function::eval(...) functions

[Prof Garth Wells]

These functions will often be called repeatedly. Should pass/store work arrays to avoid repeated dynamic memory allocations.

[Martin Sandve Alnæs]

Really? That's not minor, that's a critical performance bug. Is this a recent accident or has it always been that way?

[Prof Garth Wells]

It's been around for a long time. It's not necessarily a major performance bug because the time may be small compared to what comes before it (ie, cell searches).

I don't know what a good solution is. If the Function class keeps some scratch space, it is not thread-safe.

A big part of the problem is the confusing complexity around the ufc::function callbacks. For one, this stops a user passing through work arrays.

[Johan Hake]

Is Function::eval called by any performance critical tasks? During assemble is GenericFunction::restrict used.

[Prof Garth Wells]

@johanhake It's used when interpolating on non-matching meshes.

[Anders Logg (Chalmers)]

Are you sure this is a bottleneck? A lot of stuff happens inside non_matching_eval.

[Prof Garth Wells]

@logg It doesn't have to be as bad as bottleneck to try fixing it. I have a case where I want to call eval where I know the cell, so I don't need any searching, which ordinarily might bury the cost of the allocations.

In any case, the function is not elegantly engineered. It works, which is why I set the priority to 'low'.

[Mikael Mortensen]

I vote for it, but this is hardly a critical performance bug for non-matching interpolation. For non-matching interpolation the Function::eval may now be called hundreds of times for the same interpolation point, even though one time is enough (at least for Lagrange spaces). Now that is a critical performance bug (for interpolation), and I have addressed it here.

The function LagrangeInterpolator::interpolate calls Function::eval and it would certainly benefit from being able to preallocate or use work arrays. Not really relevant, but I actually do this already in the Probe class of fenicstools, where a Function may be evaluated repeatedly for the same location (hence the name Probe).

[Prof Garth Wells]

Bumping milestone to 1.7.

This is best dealt with with a fundamental re-think of how DOLFIN and UFC interact for Functions.

[Anders Logg (Chalmers)]

Removing milestone: 1.7 (automated comment)