Re: [Libmesh-devel] DofObject::var_to_vg()

[Roy S. <roy...@ic...>]

On Tue, 19 Jun 2018, Derek Gaston wrote:

> (Note: this falls into the category of "microptimization" but with
> my current app that's important).

I've seen this method show up in other timings too... maybe it was
RELAP-7?  Anyway, if we can speed it up your current app won't be the
only beneficiary.

> Something that consistently shows up in my timing with MOOSE and my
> new app is DofObject::var_to_vg().  It is gets called in a number of
> places throughout DofObject... and I'm wondering if it's currently
> implemented in the most optimal way.
> 
> It's doing a small loop in there and I'm wondering if it's
> necessary.  Is it not possible to directly compute the var group?
> 
> vg_dof_base() seems to do some direct calculation - can we use that
> instead?

vg_dof_base already has the variable group index vg, which is what we
can use for a direct lookup of data related to all variables in that
group; buried in that index buffer are subbuffers indexed by vg.

var_to_vg has the variable index v, and is trying to figure out vg.
We can only do that implicitly right now, since there may be an
arbitrary number of variables in each group.

I can think of ways to make that lookup faster in some cases, but
always at the cost of more space or more time in other cases or much
less code modularity, so I guess my first question is: what's your
case look like?

How many variables, and how are they grouped?

What is the heavy user of var_to_vg() for you?


A couple random ideas that might be worth trying:

We could cache a var_to_vg lookup table, and give every DofObject a
pointer to that table.  Less modular and an extra 8 bytes per object
but it'd be faster in at least some cases.

We could store n_vars in a cumulative sense, which would then let us
do a binary search instead of a linear search.  Slightly slower for
most use cases, but much faster for cases with lots of variable
groups.

We could try to avoid using var_to_vg-reliant methods in more places?
Or maybe that's already been done... we're consistently using
set_n_comp_group instead of set_n_comp, we're not using set_dof_number
internally anymore... but n_comp and dof_number both rely on
var_to_vg, and we don't use n_comp_group everywhere we might, and we
don't even *have* a dof_number_group, even though we use both n_comp
and dof_number in lots of loops that could be optimized in such a way.
---
Roy