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

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 при близком к нулю профите — хороший намек о том, что что-то пошло не так.

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

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