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

Today's software engineering word is «farpotshket.» This is a Yiddish word meaning, «broken, because someone tried to fix it.»
(с) Andr Zerozero

Схлеснулись мы тут на днях на работе по вопросу «А хорошо бы закешировать регулярку», в совершенно банальной функции

  uncached = function(data_in) {
    return /_(\d)+(?:#(\d)+)?$/.exec(data_in);
  };

сделав как-то так

  cached = (function() {
    var pattern = /_(\d)+(?:#(\d)+)?$/;
    return function(data_in) {
      return pattern.exec(data_in);
    };
  })();

Идея популярная, но многие ли задумывались о реальном профите и накладных расходах?

Результаты сравнительных тестов производительности получились странные — противоречащие моим ожиданиям, да еще и разница оказалась в пределах погрешности измерения:

uncached     13,268
cached       13,070

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

Берем complexity-report и смотрим на показатели наших функций, соответственно:

Function: uncached
    Physical SLOC: 3
    Logical SLOC: 1
    Parameter count: 1
    Cyclomatic complexity: 1
    Halstead difficulty: 2
    Halstead volume: 18.094737505048094
    Halstead effort: 36.18947501009619

Function: cached
    Physical SLOC: 8
    Logical SLOC: 3
    Parameter count: 0
    Cyclomatic complexity: 1
    Halstead difficulty: 2.6666666666666665
    Halstead volume: 22.458839376460833
    Halstead effort: 59.89023833722889

Абсолютные цифры невелики, но все же обратим внимание на показатели кода по Halstead — 30% рост difficulty и 65% рост effort при близком к нулю профите — хороший намек о том, что что-то пошло не так.

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

Короче — не делайте фигни.