Oh, while we're on the topic of optimizing assembly stuff... dof_map.dof_indices() takes up a LARGE chunk of time as well.... and closely behind that is the global_to_local mapping...

On these two we would LOVE to be able to get out _local_ dof_indices (quickly)... and use the "local" form of ghosted vectors (so no global_to_local map is necessary)...

Sorry to derail the conversation a bit... but if you start looking at the profiling of libMesh assembly these 3 things kind of go together and make up a significant chunk of runtime...


On Thu, Oct 25, 2012 at 12:34 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

On Thu, 25 Oct 2012, Boyce Griffith wrote:

> Is it even possible to have the shim class use operator[] for
> multidimensional indexing ([i][j])?  I don't know how you setup an equivalent
> to "operator[][]".  (Such a thing doesn't exist in C++, does it?)

You make your operator[](i) return a temporary of a different class
whose sole reason for existing is "store the number i, and return
element (i,j) from my operator[](j)".  It's not trivial to implement
but it's actually not relatively far down the crazy-C++-idioms rabbit
hole, and IIRC a half-decent compiler can still manage to inline it
down to a zero-cost shim.

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Libmesh-devel mailing list