Является ли строгий режим более совершенным?

Ответ 1

Является ли строгий режим, среди других его целей, позволять браузерам вводить дополнительные оптимизации или другие улучшения производительности?

Было ли это намерено делать это, я не уверен, хотя я думаю, что ответ да.

Но я могу с уверенностью сказать, что строгий режим действительно предоставляет эти возможности, и браузеры будут реализовывать их - независимо от того, была ли возможность предоставления этих возможностей преднамеренной целью для комитета ECMA. Однако я не ожидал, что все эти возможности будут приняты немедленно. Во многих случаях мантра, скорее всего, будет правильной, в первую очередь, производительность позже, потому что строгий режим широко не используется прямо сейчас. (Я работаю над движком JavaScript Mozilla и реализовал различные части строгого режима, и мы реализуем его таким образом как общее правило - хотя я мог бы, вероятно, подумать об одном или двух исключениях, если бы попытался.)

Ответ 2

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

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

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

См. также:

• Строгий режим ECMAScript 5, JSON и другие
• Билет строгого режима SpiderMonkey
• Билет строгого режима Webkit

Ответ 3

В соответствии с этим тестом "строгий режим" может быть примерно на 25% быстрее.

<div id="a">
  Q
</div>
<div id="b">
  Q
</div>
<script>
  Benchmark.prototype.setup = function() {
    function d(i) {
      var x = '999';
      y = eval("y = 8;");
      var z = x + y + i;
      document.getElementById('a').innerHTML = z;
    }

    function c(i) {
      'use strict'
      var x = '999';
      var y = eval("y = 8;");
      var z = x + y + i;
      document.getElementById('b').innerHTML = z;
    }
  };
</script>

Здесь можно протестировать: http://jsperf.com/strict-mode

<script>
  Benchmark.prototype.setup = function() {
    var nonstrict = (function() {
        return function (arg1) {
            var index;
            for (index = 1; index < arguments.length; ++index) {
                arguments[0] += arguments[index];
            }
            return arguments[0] - arg1;
        };
    }());
    var strict = (function() {
        "use strict";
        return function (arg1) {
            var index;
            for (index = 1; index < arguments.length; ++index) {
                arguments[0] += arguments[index];
            }
            return arguments[0] - arg1;
        };
    }());
    var result;
  };
</script>

Здесь тест jsPerf: http://jsperf.com/strict-mode-arguments

Ответ 4

По большей части нет. Если вы внимательно изучите документ стандартов ECMAScript 5, вы заметите, что почти все вхождения Strict Mode в алгоритмах псевдокода составляют:

  if (isStrictMode) {
      //throw an (early) SyntaxError or TypeError
  }
  else {
      //return
  }

Здесь есть две вещи:

• Проверки в строгом режиме не существовали в ECMAScript 3. Хотя он относительно лёгкий, в соответствии с реализацией JavaScript в настоящее время выполняется хотя бы одна дополнительная условная проверка по сравнению с их аналогами ECMAScript 3. Да... Я знаю, что одна проверка вроде этого горит очень мало тактов, но небольшие вещи складываются.
• Поскольку строгий режим - это прежде всего функция времени синтаксического разбора JavaScript, ваш любимый браузер не будет демонстрировать значительного снижения производительности, если для некоторого веб-сайта (например, SunSpider) включен Strict Mode. То есть ухудшение производительности происходит до, что означает, что может быть заметным для конечных пользователей, но в значительной степени неизмеримо использует объект Date для измерения времени выполнения блока