dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jan 25, 2012 at 03:21:12PM +0100, Joachim Berdal Haga wrote:
> Hi,
>
> I'm looking a bit on assembly performance at the moment. It looks like
> a lot of time (almost 25% in poisson/linear lagrange) of the time is
> spent in these two lines of GenericFunction::evaluate():
>
>   Array<double> _values(value_size(), values);
>   const Array<double> x(cell.geometric_dimension,
> const_cast<double*>(coordinates));
>
> This seems to be because of the instantiation of boost::shared_arrays.
> The ownership of the array data is not transferred (the data will be
> deleted by the caller of evaluate()), so this does not really add any
> safety.
>
> I don't have a complete picture of how Array<> is used, does the
> Python layer rely on the shared semantics (in other places)? If not,
> it might be better to make them non-shared and create copies for use
> in Python where needed.

Would it help if we do this:

1. Make GenericFunction::evaluate an inline function that just calls
   a new version of GenericFunction::eval.

2. The new version of GenericFunction::eval has the same
   implementation as the current evaluate() function.

The result would be that we get two eval() functions, one with plain
pointers and one with Array(). A C++ user (and the JIT-compiled
expressions) would use the plain pointer version, while the Array
version gets wrapped for Python subclassing (where I assume the extra
cost will not make a difference).

--
Anders