Lei, could you explain why this particular part is important to you?  As Roy pointed out, for implicit apps this never shows up as a bottleneck, and for JFNK work I think Derek agrees there are other hotspots? Why not address those if performance is an issue?

I don't want to discourage the change, but there are other deficiencies in libMesh where development could have a much bigger impact. (I swear one of these days I'll get to that blocked matrix

Because finite element objects tend to have a lot of lifetime per computation (they get reused for a lot of elements) the allocation issue is not really a driver. The dereferencing is, but as profiling reveals it is not that big of a deal. 

To answer your original question, we use a vector<vector> mostly because this section of code dates back to 2002, well before portable high performance expression templates were reliable. And based on our recent discussion you can see that the API is a trap once it is in place...

Since the allocation and storage part is currently a non-issue, I wonder if the simplest path to reduce the dereferencing hit is to store an Eigen object along side the vector<vector>, deprecate the old API, and move to the (i,j) scheme directly?  For the adventurous we could disable the backwards compatibility at configure time so only the Eigen storage existed...


On Oct 26, 2012, at 6:31 PM, "Lei Shi" <stoneszone@gmail.com> wrote:

Sorry for the late.  

It seems that in order to provide backward compatible APIs, we need such kind of shim class. Roy, What is your final decision? 

Sincerely Yours,

Lei Shi

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

On Thu, 25 Oct 2012, Boyce Griffith wrote:

Libraries like Eigen and Blitz++ use operator() for accessors rather than operator[].  How horrible would it be to go ahead and change to operator() when making this change to LibMeshNArray?

Hmmm... it would mean that we couldn't get away with starting with
just a typedef, we'd actually have to build a basic shim class right
from the start, and it would be much more of a pain in the neck for
user codes to upgrade.

On the other hand, if we did want to keep operator[] support around
indefinitely and we end up with a target class that doesn't support
it, that would mean we'd have to keep a shim class around
indefinitely... *and* we'd make it much less convenient to use a
different-semantic operator[] from the target class, e.g. the Blitz++
component accessor.

More opinions would be welcome; I'm not even sure what I'd prefer yet.

WINDOWS 8 is here.
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
Libmesh-devel mailing list