Wait - I see what you're asking... how are we going to use this to index
our data? Well, we already use "id" to index into rather large maps (yes,
regular std::map) to get at this data and we haven't seen that showing up
in our timing.... so I'm not super worried about it.
If the sparsity of it causes issues we can always continue to lookup by ID
but only translate between ID and unique_id when we need to (like for
repartitioning or "restart").
Derek
On Wednesday, July 10, 2013, Derek Gaston wrote:
> Sent from my iPad
>
> On Jul 10, 2013, at 9:50 PM, Roy Stogner
> <royst...@ices.utexas.edu<javascript:;>>
> wrote:
>
> > That'll get real sparse real fast, then. You're planning to use this
> > as the index to map or unordered_map?
>
> Yep, super sparse... So some some sort of hash map (probably
> unordered_map) of unique_id->object (but could be unique_id->id....
> don't know which one is best yet).
>
> Derek
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
