Предоставляет ли JavaScript (ECMAScript5) строгий режим существенные преимущества в производительности, чтобы его можно было широко использовать?

Question

Я читаю немного об использовании строгого режима для JavaScript, и, похоже, что, вообще говоря, идея состоит в том, чтобы навязать кодеру более жесткий набор правил, чтобы гарантировать, что движок JS может оптимизировать код лучше.Это почти похоже на JavaScript-эквивалент «Option Explicit» в Visual Basic.

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

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

Answer 1

Ну, код строгого режима, безусловно, может работать лучше, потому что он устраняет проблемы, которые усложняют оптимизацию, например, из головы:

• Оператор with был удален (Действительно сложно- если не невозможно - оптимизировать).
• Больше нет необъявленных назначений и других запретов, например (* delete varName;)
• eval не вводит объявления переменных / функций в локальную область.
• arguments.callee был удален (трудно оптимизировать (например, встраивание функции ))
• Именованные свойства индекса объекта arguments больше не отображаются динамически вименованные формальные параметры.

Answer 2

Я думаю, что причины его использования были хорошо изложены Джоном Резигом, http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/,, и, похоже, Firefox его поддержит, http://whereswalden.com/2010/09/08/new-es5-strict-mode-support-now-with-poison-pills/,, так что может быть полезно взглянуть, по крайней мере, для библиотек.

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

Answer 3

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

Я был исправлен, и, к сожалению, он не включает строгую типизацию. Исследователи потратили много лет на то, чтобы принудительно ввести тип для обнаружения ошибок во время компиляции, и теперь мы должны верить, что код хорош, или проверять его вручную или модульным тестированием. ИМХО, время, потраченное на модульное тестирование, обычно мало во многих местах, и его не следует тратить на то, что может сделать компилятор.