On Fri, May 31, 2013 at 3:18 PM, Darin Adler <da...@apple.com> wrote: > On May 31, 2013, at 1:57 PM, Brendan Long <s...@brendanlong.com> wrote: >> I hope this isn't a stupid question, but I can't find any references to what >> the difference between AtomicString and String is. > > WTF::AtomicString is a class that has four differences from the normal > WTF::String class: > > 1) It’s more expensive to create a new atomic string than a non-atomic > string; doing so requires a lookup in a per-thread atomic string hash table. > > 2) It’s very inexpensive to compare one atomic string with another. The cost > is just a pointer comparison. The actual string length and data don’t need to > be compared, because on any one thread no AtomicString can be equal to any > other AtomicString. > > 3) If a particular string already exists in the atomic string table, > allocating another string that is equal to it does not cost any additional > memory. The atomic string is shared and the cost is looking it up in the > per-thread atomic string hash table and incrementing its reference count. > > 4) There are special considerations if you want to use an atomic string on a > thread other than the one it was created on since each thread has its own > atomic string hash table. > > Generally speaking, we use AtomicString to make string comparisons fast and > to save memory when many equal strings are likely to be allocated. For > example, we use AtomicString for HTML attribute names so we can compare them > quickly, and for both HTML attribute names and values since it’s common to > have many identical ones and we save memory. > > It’s not a good idea to spend the extra cost to construct an AtomicString if > neither the comparison nor the memory savings applies. > > It’s unnecessarily costly to convert an atomic string to a non-atomic string > and then back to an atomic string, since it requires an additional hash table > lookup. Thus if you’re starting with an atomic string it’s best to keep the > value in variables of type AtomicString and AtomicStringImpl* if possible.
I don't mean to intrude, but I believe we store a bit on StringImpl that makes conversion from String and StringImpl to AtomicString fast if the underlying StringImpl is already in the AtomicStringTable: https://trac.webkit.org/browser/trunk/Source/WTF/wtf/text/AtomicString.h#L185 ALWAYS_INLINE static PassRefPtr<StringImpl> add(StringImpl* r) { if (!r || r->isAtomic()) return r; return addSlowCase(r); } Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
