Changes between Version 9 and Version 10 of EfficientStrings


Ignore:
Timestamp:
May 31, 2013 5:18:16 PM (7 years ago)
Author:
rafael.lobo@openbossa.org
Comment:

This is a summary of what was discussed on "[webkit-dev] When should I use AtomicString vs String?", it might be worth keeping it here.

Legend:

Unmodified
Added
Removed
Modified
  • EfficientStrings

    v9 v10  
    8383-->96bytes.[[BR]]
    8484Be careful when allocating strings.
     85
     86=== AtomicString VS String ===
     87
     88WTF::AtomicString is a class that has four differences from the normal WTF::String class:
     89
     90* 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.
     91* 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.
     92* 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.
     93* 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.
     94
     95We 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.
     96
     97We shouldn't use AtomicString if the string we're about to create doesn't get shared across multiple AtomicStrings. For example, if we had used AtomicString for the strings inside Text nodes, then we may end up filling up the atomic string table with all these really long strings that don't typically appear more than once.  It also slows down the hash map look up for all other atomic strings.
     98
     99''(this topic is a summary of the thread "[webkit-dev] When should I use AtomicString vs String?")''