On Thu, 9 Apr 2009, Kirk, Benjamin (JSC-EG311) wrote: > Two obvious optimizations seem possible, though. the > this->first_local_index() and this->last_local_index() both perform the same > underlying PETSc call to get *both* [local_min, local_max) and only return > the QOI. > > This could be streamlined with > > std::pair<unsigned int, unsigned int> PetscVector::local_index_range()
That's definitely a good idea. > something like that, eliminating a redundant call. Also, if this is in fact > a performance issue, we could cache these values at the expense of > additional bookkeeping. That would worry me just a little; I hate data copies that might get out of sync. > What I would suggest in this case and can take a hack at instead is that > GlobalToLocalMap be derived from std::vector. It seems natural since the > API provides a vector in the first place. we then just sort this vector and > do the lookups with binary searches, which should smoke the map in terms of > memory and access time performance. That's probably a good idea, but let's wait until we have some profiling info before we spend time on it. Obviously our intuition about this code's performance is way off - I was *not* expecting things to slow down. And it would be awful to waste a bunch of time optimizing GlobalToLocalMap only to find out that the real slowdown was in the ghosted codepath of project_vector or some such. --- Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
