<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 25, 2016 at 6:49 PM, Richard Smith via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: rsmith<br>
Date: Fri Mar 25 20:49:50 2016<br>
New Revision: 264486<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=264486&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=264486&view=rev</a><br>
Log:<br>
Don't force OnDiskHashTables to have a minimum of 64 buckets. That's<br>
preposterously large for some lookup tables -- in C++ classes generated by<br>
template instantiation, it's very common for the number of lookup results to be<br>
either 1 or 2.<br>
<br>
This reduces size of a libstdc++ module by 7-15%.<br></blockquote><div><br></div><div>Awesome!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Modified:<br>
    llvm/trunk/include/llvm/Support/OnDiskHashTable.h<br>
<br>
Modified: llvm/trunk/include/llvm/Support/OnDiskHashTable.h<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/OnDiskHashTable.h?rev=264486&r1=264485&r2=264486&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/OnDiskHashTable.h?rev=264486&r1=264485&r2=264486&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/include/llvm/Support/OnDiskHashTable.h (original)<br>
+++ llvm/trunk/include/llvm/Support/OnDiskHashTable.h Fri Mar 25 20:49:50 2016<br>
@@ -152,6 +152,22 @@ public:<br>
     using namespace llvm::support;<br>
     endian::Writer<little> LE(Out);<br>
<br>
+    // Now we're done adding entries, resize the bucket list if it's<br>
+    // significantly too large. (This only happens if the number of<br>
+    // entries is small and we're within our initial allocation of<br>
+    // 64 buckets.) We aim for an occupancy ratio in [3/8, 3/4).<br>
+    //<br>
+    // As a special case, if there are two or fewer entries, just<br>
+    // form a single bucket. A linear scan is fine in that case, and<br>
+    // this is very common in C++ class lookup tables. This also<br>
+    // guarantees we produce at least one bucket for an empty table.<br>
+    //<br>
+    // FIXME: Try computing a perfect hash function at this point.<br>
+    unsigned TargetNumBuckets =<br>
+        NumEntries <= 2 ? 1 : NextPowerOf2(NumEntries * 4 / 3);<br>
+    if (TargetNumBuckets != NumBuckets)<br>
+      resize(TargetNumBuckets);<br>
+<br>
     // Emit the payload of the table.<br>
     for (offset_type I = 0; I < NumBuckets; ++I) {<br>
       Bucket &B = Buckets[I];<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div></div>