Johan Hake wrote: > On Monday 01 June 2009 16:53:55 Garth N. Wells wrote: >> Anders Logg wrote: >>> On Mon, Jun 01, 2009 at 04:06:40PM +0200, DOLFIN wrote: >>>> One or more new changesets pushed to the primary dolfin repository. >>>> A short summary of the last three changesets is included below. >>>> >>>> changeset: 6245:30c1540b12097130e3ed48ed572819471c884a7b >>>> tag: tip >>>> user: "Garth N. Wells <gn...@cam.ac.uk>" >>>> date: Mon Jun 01 15:06:26 2009 +0100 >>>> files: dolfin/la/EpetraSparsityPattern.cpp >>>> dolfin/la/EpetraSparsityPattern.h dolfin/la/GenericSparsityPattern.h >>>> dolfin/la/SparsityPattern.cpp dolfin/la/SparsityPattern.h >>>> dolfin/la/uBLASMatrix.h description: >>>> Use std::set in SparsityPattern. >>>> >>>> Some performance issues seem to have been resolved with std::set. >>>> >>>> std::tr1::unsorted_set is faster, but requires some effort to sort. >>>> Sorting is only relevant to the uBLAS backend at this point. >>> Building the sparsity pattern seems to be slightly faster, but >>> deleting it takes significantly longer. The relative slowdown for that >>> step is a factor 15-20. >>> >>> I was wondering why we used std::vector instead of std::set, but this >>> might be the reason: It takes a *long* time to delete std::set. We >>> should look for something else. >> I recall set insertion also being dead slow, which is why I used >> std::vector with a homemade insert. Despite having programmed it, it >> took me a bit to understand what the code I wrote does which I why I >> tried set again. >> >> We should try std::tr1::unsorted_set. It's faster for insertion but I >> don't know about the delete. We can cook something up to do the sort for >> uBLAS. > > Isn't the performance issue on destruction the common problem of deleting a > lot of small objects? This would probably not be any difference with > unsorted_set? >
We don't see this with std::vector<std::vector<uint> >. unsorted_set does have the same problem with slow destruction, but this is compensated for by faster insertion. > Would it be worth trying a pooled memory management? Something like: > > #include <boost/pool/pool_alloc.hpp> > typedef std::set<int, unsigned int, boost::fast_pool_allocator<unsigned int> > > > setuint; > Yes, this is an option. Garth > Johan > >> Garth >> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> DOLFIN-dev mailing list >>> DOLFIN-dev@fenics.org >>> http://www.fenics.org/mailman/listinfo/dolfin-dev >> _______________________________________________ >> DOLFIN-dev mailing list >> DOLFIN-dev@fenics.org >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
