From: Richard Smith <richard-llvm@metafoo.co.uk>
Date: Sat, 26 Mar 2016 01:49:50 +0000 (+0000)
Subject: Don't force OnDiskHashTables to have a minimum of 64 buckets. That's
X-Git-Tag: llvmorg-3.9.0-rc1~10840
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=fef9e86f7007193ffc7f8d7c27f19cd891a9782b;p=platform%2Fupstream%2Fllvm.git

Don't force OnDiskHashTables to have a minimum of 64 buckets. That's
preposterously large for some lookup tables -- in C++ classes generated by
template instantiation, it's very common for the number of lookup results to be
either 1 or 2.

This reduces size of a libstdc++ module by 7-15%.

llvm-svn: 264486
---

diff --git a/llvm/include/llvm/Support/OnDiskHashTable.h b/llvm/include/llvm/Support/OnDiskHashTable.h
index ac978d4..4e8320f 100644
--- a/llvm/include/llvm/Support/OnDiskHashTable.h
+++ b/llvm/include/llvm/Support/OnDiskHashTable.h
@@ -152,6 +152,22 @@ public:
     using namespace llvm::support;
     endian::Writer<little> LE(Out);
 
+    // Now we're done adding entries, resize the bucket list if it's
+    // significantly too large. (This only happens if the number of
+    // entries is small and we're within our initial allocation of
+    // 64 buckets.) We aim for an occupancy ratio in [3/8, 3/4).
+    //
+    // As a special case, if there are two or fewer entries, just
+    // form a single bucket. A linear scan is fine in that case, and
+    // this is very common in C++ class lookup tables. This also
+    // guarantees we produce at least one bucket for an empty table.
+    //
+    // FIXME: Try computing a perfect hash function at this point.
+    unsigned TargetNumBuckets =
+        NumEntries <= 2 ? 1 : NextPowerOf2(NumEntries * 4 / 3);
+    if (TargetNumBuckets != NumBuckets)
+      resize(TargetNumBuckets);
+
     // Emit the payload of the table.
     for (offset_type I = 0; I < NumBuckets; ++I) {
       Bucket &B = Buckets[I];