Re: [Libmesh-devel] Exposing _boundary_side_id / Optimizing boundary_ids()

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

On Tue, 19 Jun 2018, Derek Gaston wrote:

> Sorry to send two messages in a row

It's upsetting to me when people put lots of thought into how to
optimize libMesh?  Grr?  Argh?

> but I'm wondering if it would be ok to expose
> BoundaryInfo::_boundary_side_id ?

My first inclination is "hell no" but that may just mean I haven't
thought about it enough.

I don't like exposing members since that basically freezes our data
structures.  It'd be sad if e.g. we discovered we could shave
O(log(N)) off of some heavy code by switching from multimap to
unordered_multimap, but were then precluded from doing so by backwards
compatibility concerns.

I think I'd be willing to compromise with a getter tagged
libmesh_experimental().

> The issue I'm having is that calling boundary_ids() is "slow" (and
> causes memory allocations which is actually the thing I'm trying to
> remove) because it passes in a std::vector that it fills...

> I am reusing the vec_to_fill... but it's still not enough to keep
> down the memory allocation/deallocation associated with that
> routine.

Stupid question - why not?  If you're reusing the vector then there
should only be allocation O(log2(N)) times at most, where N is the
size of your loop.  You could get that down to O(1) by calling
reserve() on the vector yourself before starting.

> Barring that - would be it ok if I make boundary_ids() reserve()
> enough size in the vec_to_fill to potentially hold all of the IDs
> from the equal_range()?  That should help out with the reallocs.

Should it?  vector::clear() isn't allowed by the C++ standard to
modify vector capacity, so if your input vector was large enough to
hold the whole range then there shouldn't be any reallocs.

> Another option is to template boundary_ids() so that I can pass in
> my own container that is statically sized (over-sized to hold the
> max number of IDs) and won't do any allocation.

If we actually need this, I don't have any objections to it, but I
don't yet understand why we need it.
---
Roy