From e85d7cc8d95a6192c97fa61323f08351738d0994 Mon Sep 17 00:00:00 2001 From: Davi de Castro Reis Date: Thu, 12 Apr 2012 16:36:23 -0300 Subject: [PATCH] Improved comments. --- cxxmph/mph_index.h | 5 +++-- cxxmph/mph_map.h | 12 ++++++++---- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/cxxmph/mph_index.h b/cxxmph/mph_index.h index c64a363..35ca9d7 100644 --- a/cxxmph/mph_index.h +++ b/cxxmph/mph_index.h @@ -10,10 +10,11 @@ // This is a pretty uncommon data structure, and if you application has a real // use case for it, chances are that it is a real win. If all you are doing is // a straightforward implementation of an in-memory associative mapping data -// structure (e.g., mph_map.h), then it will probably be slower, since that the +// structure, then it will probably be slower, since that the // evaluation of index() is typically slower than the total cost of running a // traditional hash function over a key and doing 2-3 conflict resolutions on -// 100byte-ish strings. +// 100byte-ish strings. If you still want to do, take a look at mph_map.h +// instead. // // Thesis presenting this and similar algorithms: // http://homepages.dcc.ufmg.br/~fbotelho/en/talks/thesis2008/thesis.pdf diff --git a/cxxmph/mph_map.h b/cxxmph/mph_map.h index 58b41ef..a844997 100644 --- a/cxxmph/mph_map.h +++ b/cxxmph/mph_map.h @@ -3,11 +3,15 @@ // Implementation of the unordered associative mapping interface using a // minimal perfect hash function. // -// This class is about 20% to 100% slower than unordered_map (or ext/hash_map) -// and should not be used if performance is a concern. In fact, you should only -// use it for educational purposes. +// This class not necessarily faster than unordered_map (or ext/hash_map). +// Benchmark your code before using it. If you do not call rehash() before +// starting your reads, it will be definitively slower than unordered_map. // -// See http://www.strchr.com/crc32_popcnt and new Murmur3 function to try to beat stl +// For large sets of urls, which are a somewhat expensive to compare, I found +// this class to be about 10% faster than unordered_map. +// +// The space overhead of this map is 1.93 bits per bucket and it achieves 100% +// occupation with a rehash call. #include #include