[webkit-dev] When should I use AtomicString vs String?

[Adam Barth]

On Fri, May 31, 2013 at 3:18 PM, Darin Adler <darin at apple.com> wrote:
> On May 31, 2013, at 1:57 PM, Brendan Long <self at 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