Recently we're profiling our tool for restoration for a large electronic design. And we're restoring two archive of same number of elements - one uses vector as container while the other uses set. And it appears that restoration of set is much much slower than the vector. Both the restoration called from same parent which is called just once. And vector restoration took 2% of parent while set restoration took 83% of parent. And most of set restoration time is spent in : boost::serialization::stl::archive_input_unique, std::less>, std::allocator> > >::operator ()(boost::archive::binary_iarchive&, std::set, std::less>, std::allocator> >&, unsigned) Distribution to callers: 128886 times boost::serialization::stl::load_collection, std::less>, std::allocator> >, boost::serialization::stl::archive_input_unique, std::less>, std::allocator> > >, boost::serialization::stl::no_reserve_imp, std::less>, std::allocator> >> >(boost::archive::binary_iarchive&, std::set, std::less>, std::allocator> >::insert(std::string const&) Is there any known performance problem for std::setstd::string restoration? Or do we need to do some special to overcome this performance problem of std::setstd::string? Since we need to use frequent lookup while inserting, we can't switch to vector. So, can I get better performance with hash_set or tr1::unordered_set if those are supported for boost::serialization? We're using 1.35 version of boost. Regards, ~ Soumen -- View this message in context: http://old.nabble.com/-Serialization--std%3A%3Aset%3Cstd%3A%3Astring%3E-rest... Sent from the Boost - Users mailing list archive at Nabble.com.