Improved comments.

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

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)
+// This class not necessarily faster than unordered_map (or ext/hash_map).
-// and should not be used if performance is a concern. In fact, you should only
+// Benchmark your code before using it. If you do not call rehash() before
-// use it for educational purposes.
+// 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 <algorithm>
 #include <iostream>