[LLVMbugs] [Bug 16747] New: Poor performance of degenerated unordered_multimap

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16747

            Bug ID: 16747
           Summary: Poor performance of degenerated unordered_multimap
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: hhinnant at apple.com
          Reporter: gs.libcxx.bug at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following code uses an unordered_multimap to associate very few values with
a long list of values. The example performs very poor compared to libstdc++ and
the std lib implementation of Visual Studio 2012.


#include <chrono>
#include <iostream>
#include <string>
#include <unordered_map>

int main (int argc, char* argv[]) {
  const int N = (argc > 1) ? std::stoi(argv[1]) : 123456;
  const auto begin = std::chrono::high_resolution_clock::now();
  std::unordered_multimap<int, int> map;
  for (int i = 0; i < N; ++i) {
    map.insert({i % 4, i});
  }
  const auto end = std::chrono::high_resolution_clock::now();
  const auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(end -
begin);
  std::cout << "Duration for " << map.size() << " integer inserts: " <<
ms.count() << "ms" << std::endl;
}



Results on Linux (SLES 11.2):
=============================
clang-3.2 with libc++ from 2013-01-31: 
Duration for 123456 integer inserts: 21605ms

clang-3.3 with libc++ from 2013-01-31: 
Duration for 123456 integer inserts: 21836ms

gcc-4.6 with GLIBCXX_3.4.16:
Duration for 123456 integer inserts: 7ms


Results on Windows 2008 Server:
===============================
Visual Studio 2012 SP3:
Duration for 123456 integer inserts, count=123456: 15ms

Results on OS X 10.8.4:
=======================
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn):
Duration for 123456 integer inserts: 18702ms


The Linux and Windows results are on the same hardware, the OS X test was run
on a Mac Pro 2.93GHz and has similar performance to the Linux/Windows hardware.

I am building an inverse map for fast look-up. In most cases this works fine.
In rare cases the map degenerates to a few values being mapped to a long list.
In these rare case the performance deteriorates badly compared to other
implementations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130730/9a9b6fbc/attachment.html>