Version 9 (modified by, 11 years ago) (diff)



Null and empty

Passing a null string is very efficient. Whenever possible, use a null String instead of an empty String.

From literal

Each String type has a efficient constructor to initialize the string from a literal:

  • String foo = ASCIILiteral("bar");
  • String foo("bar", String::ConstructFromLiteral);

The safest option is ASCIILiteral("Foo"). It produces the same code size as String("Foo") while being faster.

The difference between the version is if the length of the string is included or not. Having the size given in the constructor makes the constructor faster. Having the size also makes the code bigger, which is a problem when the code is executed infrequently.

In general, use ASCIILiteral unless you can show improvement on a benchmark by using ConstructFromLiteral.

AtomicString from literal

AtomicString should always use the full template version:

  • AtomicString foo("bar", AtomicString::ConstructFromLiteral);

The reason is that version gives the possibility to compute the hash at compile time in the future.

Not creating a string

Many operations can be more efficient with a literal. Do not create a String when it is not needed.


  • foo.startsWith("bar")
  • foo.startsWith(ASCIILiteral("bar"))
  • foo.startsWith(String("bar"))

The first version is the fastest.


There are two efficient way to concatenate strings: StringBuilder and StringOperators. Anything else is pretty much less efficient when doing more than one operations.


str = text;
str.append("a"); // == str.append(String("a"));
str += bar;

Should be (StringOperators):

str = text + 'a' + foo + bar;

Note the use of 'a' here instead of "a" as it is more efficient.


str = foo;
for (size_t i = 0; i < foobars; ++i)
   str += "bar";

should be:

StringBuilder builder;
for (size_t i = 0; i < foobars; ++i)
str = builder.toString();

Note: If you need to append a literal char, builder.append('c'); is more efficient than builder.appendLiteral("c");


Any of the string class uses memory on the heap to allocate a StringImpl. The only way to avoid allocating new memory is to use the methods taking a constant literal.

On 64bits, the memory used for StringImpl vary between 28 bytes to (28 + length + length * 2) bytes for a string from copy that has been converted to 16 bits.

For example, a 10 characters string from copy converted to 16bits + the allocators alignment would typically take:
-28 + 10 = 38 -> typically allocated to 64bytes
-10 * 2 = 20 -> typically allocated to 32bytes
Be careful when allocating strings.