Конкатенация строк по сравнению со строкой буферизует в JavaScript

Даже если бы оно было истинным и соединение () было быстрее конкатенации, это не имело бы значения. Здесь мы говорим о крошечных миллисекундах, которыми можно пренебречь.

Я всегда предпочитаю хорошо структурированный и легко читаемый код микроскопическому повышению производительности, и я думаю, что использование конкатенации выглядит лучше и его легче читать.

Просто мои два цента.

В принципе книга правильная. Присоединение к массиву должно быть намного быстрее, чем повторное соединение с одной и той же строкой. Как простой алгоритм на неизменяемых строках, он явно быстрее.

Уловка заключается в том, что авторы JavaScript, в значительной степени неопытные дилетанты, написали массу кода, который использует конкатенацию, и относительно мало «хороших» код, использующий такие методы, как объединение массивов. В результате авторы браузеров могут добиться большего увеличения скорости на средней веб-странице, обслуживая и оптимизируя «плохой», более распространенный вариант конкатенации.

Вот что произошло. В более новых версиях браузера есть довольно сложная оптимизация, которая определяет, когда вы выполняете множество конкатенаций,

В моей системе (IE 8 в Windows 7) время StringBuilder в этом тесте составляет примерно 70–100% в диапазоне, то есть он нестабилен, хотя среднее значение составляет около 95% от нормального добавления.

Хотя сейчас легко просто сказать «преждевременная оптимизация» (и я подозреваю, что почти во всех случаях это так), есть вещи, которые стоит учитывать:

Проблема с повторением конкатенация строк приводит к повторному выделению памяти и повторяющимся копиям данных (расширенные строковые типы данных могут уменьшить / устранить большую часть этого, но пока давайте продолжим предполагать упрощенную модель). Отсюда можно задать несколько вопросов:

• Какое распределение памяти используется? В наивном случае каждая строка str + = x требует выделения новой памяти str.length + x.length. Стандартный C malloc, например, является довольно плохим распределителем памяти. Реализации JS претерпели изменения за эти годы, включая, среди прочего, улучшенные подсистемы памяти. Конечно, эти изменения на этом не заканчиваются и затрагивают действительно все аспекты современного JS-кода. Поскольку теперь древние реализации могли быть невероятно медленными при выполнении определенных задач, это не обязательно означает, что те же проблемы все еще существуют или в той же степени.

• Как и выше, реализация Array.join очень важна . Если он НЕ выделяет предварительно память для последней строки перед ее построением, он экономит только на затратах на копирование данных - сколько ГБ / с в наши дни является основной памятью? 10 000 x 50 - это не предел. Ожидается, что умная операция Array.join с ПЛОХИМ АЛЛОКАТОРОМ ПАМЯТИ будет работать немного лучше, потому что количество перераспределений уменьшается. Ожидается, что эта разница будет сведена к минимуму по мере уменьшения затрат на выделение ресурсов.

• Код микротеста может иметь изъяны в зависимости от того, создает ли механизм JS новый объект для каждого строкового литерала UNIQUE или нет. (Это приведет к смещению его в сторону метода Array.join, но его следует рассматривать в целом).

• Тест действительно является микротестом :) Увеличение растущего размера должно повлиять на производительность на основе любых или всех (а затем некоторых) вышеуказанных условий. Обычно легко показать крайние случаи в пользу того или иного метода - ожидаемый вариант использования, как правило, более важен.

Хотя, честно говоря, для любой формы разумного построения строк я бы просто используйте обычную конкатенацию строк до тех пор, пока она не будет определена как узкое место, если вообще когда-либо.

Я бы перечитал приведенное выше утверждение из книги и посмотрел, есть ли другие неявные соображения, которые автор действительно имел в виду, например «для очень больших строк» ​​или «безумное количество строковых операций» или «в JScript / IE6» и т. д. Если нет, то такой оператор примерно так же полезен, как «Вставить сортировку O (n * n)»

На самом деле у меня есть некоторый опыт в этой области, поскольку мой основной продукт - это большое веб-приложение только для IE, которое выполняет ОЧЕНЬ много конкатенации строк для создания XML-документов для отправки на сервер. . Например, в худшем случае на странице может быть 5-10 окон iframe, каждый с несколькими сотнями текстовых полей, каждое из которых имеет 5-10 свойств expando.

Для чего-то вроде нашей функции сохранения мы перебираем каждую вкладку (iframe) и каждый объект на этой вкладке, вытащите все свойства expando для каждого объекта и поместите их все в гигантский XML-документ.

При профилировании и улучшении нашего метода сохранения мы обнаружили, что использование конкатенации строк в IE7 было намного медленнее, чем используя метод массива строк. Некоторые другие интересные моменты заключались в том, что доступ к свойствам expando объекта DOM очень медленный, поэтому вместо этого мы помещаем их все в массивы javascript. Наконец, создание самих массивов javascript лучше всего выполнять на сервере, а затем вы записываете их на страницу как буквальный элемент управления, который будет выполняться при загрузке страницы.

Хорошо, по этому поводу есть связанный модуль:

http://www.openjsan.org/doc/s/sh/shogo4405/String/Buffer/0.0.1/lib /String/Buffer.html

Это эффективное средство создания буферов String с использованием

var buffer = new String.Buffer();
buffer.append("foo", "bar");

. Это самый быстрый вид реализации буферов String, о котором я знаю. Прежде всего, если вы реализуете строковые буферы, не используйте push, потому что это встроенный метод, и он медленный, поскольку одно нажатие выполняет итерацию по всему массиву аргументов, а не просто добавляет один элемент.

Все это действительно зависит от реализации метода соединения, некоторые реализации метода соединения очень медленные, а некоторые относительно большие.

Как мы знаем, не все браузеры одинаковы. Из-за этого производительность в разных областях гарантированно будет отличаться от браузера к браузеру.

Кроме того, я заметил те же результаты, что и вы; однако после удаления ненужного класса буфера и простого использования массива напрямую и строки из 10000 символов результаты были еще более точными / согласованными (в FF 3.0.12): http://jsbin.com/ehalu/

Если вы не занимаетесь конкатенацией строк, я бы сказал, что этот тип оптимизации является микрооптимизацией. Возможно, вам лучше потратить время на ограничение DOM перекомпоновки и запросов (обычно использование document.getElementbyById / getElementByTagName ),