Производительность закрытия Javascript

Я работаю некоторое время в javascript и обычно делаю что-то вроде этого только для кэширования значений свойств функций, объявленных внутри глубокой структуры или "пространства имен"

//global scope
(function ($, lib) {
  //function scope 1
  var format = lib.format, // instead of calling lib.format all the time just call format
    touch = lib.pointer.touch, //instead of calling lib.pointer.touch each time just touch
    $doc = $(document),
    log = logger.log; //not console log...


  $doc.on('app:ready', function () {
    //function scope 2
    $doc.on('some:event', function (e) {
      //function scope 3
      //use the cached variables
      log(format('{0} was triggered on the $doc object', e.type);
    });

    $doc.on(touch, function (e) {
      //function scope 3
      log(format('this should be {1} and is... {0} ', e.type, touch);
    });
  }); 
}(jQuery, lib));

Я делал это, потому что:

• как ленивый, как я, писать прикосновение кажутся более привлекательными, поскольку писать lib.pointer.touch, даже когда мощные IDE с фантастическим автозаполнением могут помочь в этом, коснуться короче.
• минимизатор может преобразовать эту единственную приватную переменную в одну буквенную переменную, поэтому она также имеет смысл для меня (я знаю, я знаю, никогда не оптимизирую слишком рано, но это кажется безопасным, я думаю)

Весь написанный таким образом код, по-видимому, работает прилично на мобильных устройствах и настольных браузерах, поэтому кажется, что это безопасная практика (в "практике", каламбур). Но я с тех пор полагаюсь на замыкания, а внутренние функции должны создавать замыкание, чтобы сохранить контекст, который был объявлен мне интересно...

• если функция не использует переменные из внешнего контекста (свободные переменные)... является ли контекст закрытия еще сохраненным? (или если дерево дерева падает в лес, и никто не слышит его, он все еще делает звук аварии? hehe) Я знаю, что это может варьироваться в зависимости от движка javascript, потому что ECMA ничего не говорит о том, требуется ли сохранить контекст или нет, когда переменные извне не доступны.

• если указанное выражение истинно... будет ли этот блок кода более эффективным?

  //global scope
  (function ($, lib) {
    //function scope 1
    var format = lib.format,
      touch = lib.pointer.touch,
      $doc = $(document),
      log = console.log;
  
    $doc.on('app:ready', function () {
  
      (function ($doc, touch, lib, format) {
        // since all the variables are provided as arguments in this function
        // there is no need to save them to the [[scope]] of this function
        // because they are local to this self invoking function now
        $doc.on('some:event', function (e) {
          //function scope 3
          //use the cached variables
          log(format('{0} was triggered on the $doc object', e.type);
        });
  
        $doc.on(touch, function (e) {
          //function scope 3
          log(format('this should be {1} and is... {0} ', e.type, touch);
        });
      }($doc, touch, lib, format));      
  
    }); 
  
  }(jQuery, lib));
  

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

• Как я могу правильно измерить потребление памяти в моей javascript-библиотеке надежным способом? У меня есть 100x маленьких модулей javascript, которые находятся внутри непосредственных функций самозапуска, в основном, чтобы избежать переполнения переменных в глобальном контексте. Таким образом, все они завернуты в модули, очень похожие на блок кода, упомянутый выше.

• будет ли он лучше влиять на кеширование переменных ближе, даже если это будет означать, что мне придется повторять объявления переменных ближе к тому, где они будут использоваться?

• У меня такое чувство, что для поиска переменной не в текущем локальном контексте, механизм сначала рассмотрит родительскую область и перечислит все переменные на этом уровне... чем больше переменных на уровень, тем хуже вероятно, будет производительностью, ища переменную.

• попытаться найти переменную undefined из внутренних замыканий будет самой дорогой, потому что по определению переменная будет первым поиском в родительской области до тех пор, пока глобальная область действия, и не найдя ее, заставит двигатель наконец, достичь глобального масштаба. Это правда? являются ли механизмы, оптимизирующие этот вид поиска?

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

В соответствии с этим тестом...

http://jsperf.com/closures-js

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

update: он указал мне, что этот вопрос слишком велик. Извините, я попытаюсь сломать мелкие детали. Этот вопрос был мотивирован в основном любопытством, как я сказал, производительность кажется незначительной даже на мобильных устройствах. Благодарим вас за все ваши отзывы.

Ответы

(function(){
   var hello = "hello", world="world";
    setTimeout(function(){
        debugger;
        console.log(hello);
    });
})()