Bug 1477632 - Always inline PLDHashTable::SearchTable(). r=froydnj This speeds up BenchCollections.PLDHash as follows: > succ_lookups fail_lookups insert_remove iterate > 42.8 ms 51.6 ms 21.0 ms 34.9 ms > 41.8 ms 51.9 ms 20.0 ms 34.6 ms > 41.6 ms 51.3 ms 19.3 ms 34.5 ms > 41.6 ms 51.3 ms 19.8 ms 35.0 ms > 41.7 ms 50.8 ms 20.5 ms 35.2 ms After: > succ_lookups fail_lookups insert_remove iterate > 37.7 ms 33.1 ms 19.7 ms 35.0 ms > 37.0 ms 32.5 ms 19.1 ms 35.4 ms > 37.6 ms 33.6 ms 19.2 ms 36.2 ms > 36.7 ms 33.3 ms 19.1 ms 35.3 ms > 37.1 ms 33.1 ms 19.1 ms 35.0 ms Successful lookups are about 1.13x faster, failing lookups are about 1.54x faster, and insertions/removals are about 1.05x faster. On Linux64, this increases the size of libxul (as measured by `size`) by a mere 16 bytes. MozReview-Commit-ID: 8Lefuo5ico7

--- a/xpcom/ds/PLDHashTable.cpp
+++ b/xpcom/ds/PLDHashTable.cpp
@@ -346,19 +346,20 @@ PLDHashTable::Clear()
 {
   ClearAndPrepareForLength(kDefaultInitialLength);
 }
 
 // If |Reason| is |ForAdd|, the return value is always non-null and it may be
 // a previously-removed entry. If |Reason| is |ForSearchOrRemove|, the return
 // value is null on a miss, and will never be a previously-removed entry on a
 // hit. This distinction is a bit grotty but this function is hot enough that
-// these differences are worthwhile.
+// these differences are worthwhile. (It's also hot enough that
+// MOZ_ALWAYS_INLINE makes a significant difference.)
 template <PLDHashTable::SearchReason Reason>
-PLDHashEntryHdr* NS_FASTCALL
+MOZ_ALWAYS_INLINE PLDHashEntryHdr*
 PLDHashTable::SearchTable(const void* aKey, PLDHashNumber aKeyHash)
 {
   MOZ_ASSERT(mEntryStore.Get());
   NS_ASSERTION(!(aKeyHash & kCollisionFlag),
                "!(aKeyHash & kCollisionFlag)");
 
   // Compute the primary hash address.
   PLDHashNumber hash1 = Hash1(aKeyHash);