Скорость: аргумент-строка vs аргумент-объект со строкой
 

В общем, дело касатется HTML-парсера.

Каждый тэг представляется как токен:

function Token(name, attributes) {
    /** @member {String} */
    this.name = name;
    /** @member {Array} */
    this.attributes = attributes;
}

Каждый токен отправляется на обработку в функцию. Сейчас это сделано так:

/**
 * @param {String} name
 * @param {Array} attributes
 */
function processStartTag(name, attributes) {}

processStartTag(token.name, token.attributes);

Вопрос: насколько эффективней будет отрефакторить код так:

/**
 * @param {Token} token
 */
function processStartTag(token) {}

processStartTag(token);

Ведь по идее в первом варианте строка постоянно копируется. В случае с объектом будет просто передаваться ссылка на объект.

Блин, че то я сам не додумался потестить :)
Действительно, разница неощутимая между моими вариантами. Значит будем искать другие места для оптимизации )

Дзен-трансгуманист, если есть время+желание, глянь пожалуйста своим зорким взгядом https://github.com/aredridel/html5/tree/dev/lib (TreeBuilder и Tokenizer).

Хотя наверно непосвященному будет трудно сориентироваться в такой груде кода.

Первая цель - 100% соответствие спецификации HTML5 - достигнута.
Щас вот занимаюсь оптимизацией. Ибо по сравнению с дефолтным парсером jsdom либы этот парсер проигрывает эдак раза в четыре. Понятно, что он будет проигрывать при любых обстоятельствах, но уверен, что разницу можно сократить.

HTML размета - такая срань, костыль на костыле. Но че поделать... XML (XHTML2) не всем по нраву. Да и учитывая что подавляющее большинство сайтов поддерживается кривыми ручками - XML бы возненавидели, ибо он ошибок не прощает. Вот и получается HTML-парсер в десять раз сложней и запутанней чем XML. Плюс при каждом изменении спецификации (новый тег или атрибут) - приходится править парсер. Это все явно не красивые решения, но зато владельцы сайтов довольны, а контент всегда доступен - это важнее красоты реализации.