Почем оптимизация или «бесплатных завтраков не бывает»

[meettya]

ХМ… пруф?

У меня вот как-то другие получаются результаты:

  var n, re1, re2, res;

  re1 = /test/;

  re2 = /test/;

  res = (function() {
    var _i, _results;

    _results = [];
    for (n = _i = 0; _i <= 1; n = ++_i) {
      _results.push(/test/);
    }
    return _results;
  })();

  console.log('re1 === re1 ->', re1 === re1); // re1 === re1 -> true

  console.log('re1 === re2 ->', re1 === re2); // re1 === re2 -> false

  console.log('res[0] === res[1] ->', res[0] === res[1]); // res[0] === res[1] -> false

Или я не верно понял идею?

поиск продолжается с места предыдущего найденного результата

Это о чем? я знаю только о поведении реплейса с флагом 'g' и экспериментальном флаге 'y', но у нас тут другая ситуация вроде.

PS. А за что человека-то заминусовали — все верно заметил.

[meettya]

О как.
Могу я попросить ссылку на документацию (вероятно в реализациях браузеров?) об этом факте?

[meettya]

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

Изменения в спеках и объяснялка на SO.

Я вот знаю про скрытые классы при создании объекта, про преобразования массива если он содержит разные типы данных, про преобразование полиморфных функций, а вот по поводу «скомпилированной сущности» в отношении регулярок — не, не видел. Может лишнего удумали?

[Vidmich]

странно видеть +9 на коментарии о «поиск продолжается с места предыдущего найденного результата». в данном примере регулярка без /g и соответственно, сколько бы раз exec этой регулярки ни вызывали, он будет делать поиск с начала.

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

[tenbits]

Это называется пулом (interning). Думаю ради производительности вы так не делаете:

var addX = (function(){
    var x = 'x';
    return function(str){ return str + 'x' }
}());

НО, такие вещи хорошо выносить в константы, и вовсе не в целях производительности.

пс. и результат будет совсем другим если использовать new RegExp(reg); jsperf/2

[meettya]

Погуглил про interning, выяснил что JS сам интернит строки-как-литерал, а динамически создаваемые — нет.
Однако идеи приведенного примера так и не понял — есть переменная, которая не используется, замыкание по идее возвращающее то же самое — профит-то в чем?

[tenbits]

Interning также относится и к инлайновым регуляркам. А в примере опечатка — хотел привести аналогию с тем, как вы «кешируете» regexp:

//..
var x = 'x';
return function(str) { return str + x; }

[gandjustas]

А с чего вообще взяли что надо что-то кешировать? Работало недостаточно быстро? Данные провайдера были?

[meettya]

Кто знает :) Строим на века, вдруг в этом месте будет лаг и интерфейс пользователя фризоваться начнет? :)

На мой вкус ничего там делать было не надо, данных проФайЛера (я правильно понял?) не было конечно — virgin premature.

[NoN]

Проверьте с new RegExp() — он, в отличие от инлайнового синтаксиса, должен создаваться каждый раз.

javascript.ru/basic/regular-expression#statichnye-regekspy

[meettya]

Он и инлайновый-то каждый раз новый создается — пруф
Просто инлайновый быстрее — по многим очевидным причинам.

[Lure_of_Chaos]

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

[meettya]

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

Ну и основная идея поста была не в том, что что-то можно оптимизировать, а в том, что это накладно. Я не оперирую терминами «читабельность» и т.д. Тупо цифры: сложность — +столько-то, размер — +столько-то, effort — +столько-то. И в итоге поддержка кода превращается в ад. Как бы так вот.

PS. хм, ну и на что тут будет похож вариант «без регулярок»?

[lahmatiy]

Все зависит от того как вы используете RegExp и насколько он большой. В вашем случае это ничего не дает, но если вы создаете регулярку при каждом выполнении функции (new RegExp), то кеш может значительно ускорить функцию.
В вашем случае гораздо большего выигрыша можно получить изменив само регулярное выражение на /_\d+(\d)(?:#\d+(\d))?$/ — и более понятно, и быстрее на ~50%

[lahmatiy]

Погорячился, мой вариант регулярно выражения получился не эквивалентным — исправленный вариант работает примерно так же.