Нужно ли чистить строки в JavaScript?

А что такое бага? Если интерпретатор роняет хост, неожиданным образом это бага или нет? В среке такого нет, что надо чистить строки, наоборот, строка примитив и, по идее, это не забота програмиста, что конкретные реализации языка ведут себя подобным образом. Поведение iframe в ios тоже не бага, но тоже удивительно, когда блок, плевав на явно указанные размеры, увеличивает сам себя.

deleted

var stringCopy = function(str) {
  var strCopy = '';

  for (var i = 0; i !== str.length; i++) {
    strCopy += String.fromCharCode(str.charCodeAt(i));
  }

  return strCopy;
};

console.time('Timer');
for (var i = 0; i !== 100000; i++) {
  'Some text'.split('').join('');
}
console.timeEnd('Timer'); // Timer: 55.083984375ms


console.time('Timer');
for (var i = 0; i !== 100000; i++) {
  stringCopy('Some text');
}
console.timeEnd('Timer'); // Timer: 52.052978515625ms

Насколько я понимаю, %FlattenString (как и использующая его flatstr) не про то и здесь она не поможет — она "уплощает" cons strings (строки, образованные в результате конкатенации), но sliced strings она возвращает без изменений (по сути своей её реализация не слишком сложна).

Собственно, как уже написал ниже flapenguin — применительно к описанной статье проблеме %FlattenString поможет только если сначала к "проблемной" sliced string что-нибудь прибавить (и получится тот самый (' ' + str).slice(1)).

std::string, const std::string &, std::string && и std::string_view

str = Number(str);

str - 0 аналогично. Чем хуже явный Number(str) например?

В Firefox есть точно та же проблема, только максимальная "короткая" строка не 12 байт, как в Chrome, а 23 / 11 символов (для Latin1 / двухбайтных — см. раздел inline strings по ссылке). На 24 символах проблема воспроизводится. Кстати, следует учитывать, что выбор режима между Latin1 и двухбайтным выполняется исключительно по тому, в каком режиме была изначальная строка — то есть если там был Юникод за пределами Latin1, то и все подстроки будут оставаться ссылками по лимиту в 11 символов, а не 23.

Что ещё веселее, если внимательно посмотреть на результаты теста в JSPerf на Firefox, то окажется, что "решение" через (' ' + str).slice(1) работает за время, не зависящее от длины подстроки. Дело в том, что в Firefox эта операция выполняется через строку типа Rope и не приводит к "отсоединению" от базовой строки, то есть не выполняет свою задачу. Лишний раз видим, что самые быстрые решения зачастую оказываются менее надёжными.

Проверил на node v8.10.0 и результат отличается в зависимости от содержимого строки.

Если строка состоит из ASCII символов, то кодирование в utf8 и utf16 занимает примерно одно время:

> str = "w".repeat(15).repeat(1024);

> start = new Date(); for(var i = 0; i < 10000; i++) { Buffer.from(str, 'utf8').toString('utf8') }; (new Date() - start)
319

> start = new Date(); for(var i = 0; i < 10000; i++) { Buffer.from(str, 'utf16le').toString('utf16le') }; (new Date() - start)
330

Но если диапазон значений шире, то utf8 замедляется в 8 раз, а utf16 ускоряется в три. В результате utf16 быстрее в 26 раз.

> str = "ш".repeat(15).repeat(1024);

> start = new Date(); for(var i = 0; i < 10000; i++) { Buffer.from(str, 'utf8').toString('utf8') }; (new Date() - start)
2615

> start = new Date(); for(var i = 0; i < 10000; i++) { Buffer.from(str, 'utf16le').toString('utf16le') }; (new Date() - start)
101

Очевидно, что в V8 внутреннее представление строки меняется в зависимости от его содержимого. В общем случае utf16 предпочтительнее.

function clearString5(str) {
  return Buffer.from(str, 'utf16le').toString('utf16le');
}

711.1723950000014 // utf-8
635.6162950000726 // utf-16

53.19643200002611 // flatstr