Hi! I am developing an application with very intensive boost::filesystem::path usage. At certain moment application start to be slowly and I start profiler. Profiler shows me that std::map<fs:path, ....> is painfully slow due path::operator <() that do lexicographical compare , that do void iterator_helper<Path>::do_increment( iterator & itr ) that is really slow. So I have replaced std::map on boost::unordered_map.. and didn't get expected performance gain. Profiles show me that path::operator <() hit count 200000 and now only 100000. That tooooo much. Further investigation shows that problem was path::operator ==() used in unordered_map. I understand that operator == can be implemented using strict weak ordering concept, but for filesystem::path. Why not implement it as: bool path::operator == (const path& lhs, const path& rhs) const { return lhs.string() == rhs.string(); } ?
On Sat, Jan 17, 2009 at 6:11 AM, Konstantin Litvinenko <to.darkangel@gmail.com> wrote:
Hi!
I am developing an application with very intensive boost::filesystem::path usage. At certain moment application start to be slowly and I start profiler. Profiler shows me that std::map<fs:path, ....> is painfully slow due path::operator <() that do
lexicographical compare
, that do
void iterator_helper<Path>::do_increment( iterator & itr )
that is really slow.
So I have replaced std::map on boost::unordered_map.. and didn't get expected performance gain. Profiles show me that path::operator <() hit count 200000 and now only 100000. That tooooo much. Further investigation shows that problem was path::operator ==() used in unordered_map. I understand that operator == can be implemented using strict weak ordering concept, but for filesystem::path. Why not implement it as:
bool path::operator == (const path& lhs, const path& rhs) const { return lhs.string() == rhs.string(); }
Good question. While the other relationals have to use std::lexicographical_compare(), operators == and != can do a simple string compare, as you suggest. SVN trunk updated. It is a bit too late for these changes to make it into 1.38.0, however. It would be interesting if you could report back what impact that change has on you timings. Thanks, --Beman
Beman Dawes wrote:
Good question.
While the other relationals have to use std::lexicographical_compare(), operators == and != can do a simple string compare, as you suggest.
SVN trunk updated. It is a bit too late for these changes to make it into 1.38.0, however.
Thanx!!!
It would be interesting if you could report back what impact that change has on you timings.
There is nothing unexpected to report :). Doing typedef boost::filesystem::path location_t; struct location_equal_to : std::binary_function<location_t, location_t, bool> { bool operator()(const location_t& lhs, const location_t& rhs) const { return lhs.string() == rhs.string(); } }; to use location_equal_to predicate in unordered_map, I got no more do_increment and... remove this bottleneck at all. Can't say about numbers but this operator == replacement was very helpful.
participants (2)
-
Beman Dawes -
Konstantin Litvinenko