It turns out that I wasn't reusing the vector as well as I thought - which
was causing some of the re-allocation. That is solved now so the
re-allocation is at a minimal level. I'm doing a reserve() myself to put
plenty of space in that vector to keep down re-allocation.
That said: I would still like to think about an interface that doesn't
involve any allocation. Even just one that returns the results of the
equal_range() would be nice.
Derek
On Wed, Jun 20, 2018 at 8:25 AM Roy Stogner <royst...@ices.utexas.edu>
wrote:
>
> 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
