(Concept patch) Simplify WTF::HashTable::add() return value for size and performance

Source/core/css/CSSSegmentedFontFace.cpp

Index: Source/core/css/CSSSegmentedFontFace.cpp
diff --git a/Source/core/css/CSSSegmentedFontFace.cpp b/Source/core/css/CSSSegmentedFontFace.cpp
index 9a028571449e660f460d2610d32e289e70193dc9..44b1fc0e31ad0f8563413a6bfb993416f20e89c1 100644
--- a/Source/core/css/CSSSegmentedFontFace.cpp
+++ b/Source/core/css/CSSSegmentedFontFace.cpp
@@ -92,9 +92,9 @@ void CSSSegmentedFontFace::addFontFace(PassRefPtr<FontFace> prpFontFace, bool cs
     if (cssConnected) {
         m_fontFaces.insertBefore(m_firstNonCssConnectedFace, fontFace);
     } else {
-        FontFaceList::AddResult result = m_fontFaces.add(fontFace);
+        m_fontFaces.add(fontFace);
         if (m_firstNonCssConnectedFace == m_fontFaces.end())
-            m_firstNonCssConnectedFace = result.iterator;
+            m_firstNonCssConnectedFace = m_fontFaces.find(fontFace);

[Inactive, 2014/02/04 14:21:33]

So for the cases where the caller of add() expects an iterator, we have to do an
additional call to find() and thus an extra lookup? This seems unfortunate.

[adamk, 2014/02/04 16:29:34]

This is my objection, too. Many uses of add() are intentionally trying to avoid
extra hash lookups, so while this change might save on binary size it's trading
runtime for that.

Additionally, given the above, it seems your claim in the CL description, that
the returned iterator "is never used as an iterator" is incorrect (in this case,
and in other cases where add() is used to avoid a double hash lookup, the fact
that it's an iterator is used).

     }
 }