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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
