Is strict mode more performant?
Asked Answered
B

4

81

Does executing javascript within a browser in 'strict mode' make it more performant, in general? Do any of the major browsers do additional optimisation or use any other techniques that will improve performance in strict mode?

To rephrase slightly, is strict mode intended, amongst its other goals, to allow browsers to introduce additional optimisations or other performance enhancements?

Batik answered 30/6, 2010 at 1:43 Comment(7)
Which browsers are supporting ECMAScript 5 now anyway?Handcraft
@Jamie kangax.github.com/es5-compat-tableDubois
@Jamie Wong - see #2280615Batik
Thanks. Seems based on that that the performance of strict mode isn't going to matter for a while (in browsers).Handcraft
@Matthew: nice link! @sje397: the only complete ECMAScript 5 implementation on that list is BESEN (never heard of it either) and it's homepage notes the following: "Strict code runs faster than non-strict code, for that reason please use preferably "use strict" where is it possible"Caucasoid
arguments.callee is not allowed in 'strict' ecmascriptFirkin
IIRC Douglas Crockford's claims somewhere in this talk that the with keyword not only performs badly, but just having it in the language makes the entire language slower. This link from CMS' answer says the with keyword doesn't work in strict mode, so that would seem to indicate at least the potential for some speed-up.Withdrawal
F
30

Is strict mode intended, amongst its other goals, to allow browsers to introduce additional optimisations or other performance enhancements?

Whether or not it was intended to do this, I'm not sure, although I think the answer is yes.

But I can say with certainty that strict mode does provide these opportunities, and browsers will implement them -- regardless whether providing those opportunities was an intentional goal for the ECMA committee. However, I wouldn't expect all those opportunities to be taken immediately. In many cases the mantra is likely to be correctness first, performance later, because strict mode is not widely used right now. (I work on Mozilla's JavaScript engine and have implemented various parts of strict mode, and we're implementing it this way as a general rule -- although I could probably think of an exception or two if I tried.)

Fiedler answered 9/1, 2011 at 23:50 Comment(1)
Yes, strict mode's design goal was to enable lexical scoping (this is why things like with are disabled). It was the intention from day one.Tody
H
23

The strict mode is not really about performance, it a strict variant of the language, its main goal is to avoid what are considered to be error-prone features.

Basically its goal is to make the language safer, introducing are a lot of semantical changes, also additional error checking is made, and erros are noisy, in non-strict code things only silently fail.

About performance, I think browser vendors are now having a hard time now implementing strict mode, the problem is that the JS engines are mostly based on ECMAScript 3, and implementing the strict mode is not easy, since the scope of strictness is very flexible, you can mix non-strict and strict code.

See also:

Hypogeal answered 30/6, 2010 at 2:22 Comment(3)
+1 for the links. I don't quite see how that third sentence has anything to do with performance though.Batik
from here (seems credible): 'What John [Resig] doesn't mention is that strict mode will probably lead to greater performance. If the browser is told "I declare this code to be good and right", it can spend less time handling ambiguities, and get on to the business at hand.'Batik
@sje397: Another benefit of strict mode is that if a function declares a local variable foo and does not define any nested functions which capture it, it stores a number into foo before the first time it's read, and never stores anything other than a number into foo, then there's no way a called function (or anything else) can cause foo to hold anything other than a number. It's pretty easy to determine that the aforementioned conditions hold, and working with numbers can easily be made much faster than working with polymorphic objects that happen to be numbers.Billet
V
14

According to this test "strict mode" can be about 25% faster.

<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>

This can be tested here: http://jsperf.com/strict-mode


Interestingly, manipulation of the arguments array can be around 6 times faster in "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>

Here's the jsPerf test: http://jsperf.com/strict-mode-arguments

Virgel answered 11/5, 2015 at 9:9 Comment(1)
On my Chrome browser, today in 2017, the non-strict version is respectively about 15% and 70% slower than the strict version in your benchmarks. I guess that means the performance difference is smaller than it used to be, but still rather significant. Any idea what causes these differences in performance?Raker
G
3

For the most part, no. If you closely examine the ECMAScript 5 standards document, you'll notice that pretty much all occurrences of Strict Mode in the pseudo-code algorithms amount to:

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

There's two things to note about this:

  1. The checks on Strict Mode didn't exist in ECMAScript 3. While it's relatively lightweight, conforming implementations of JavaScript are now running at least one extra conditional check compared to their ECMAScript 3 counterparts. Yeah...I know a single check like this burns very few clock cycles, but little things add up
  2. Because Strict Mode is primarily a parse time feature of JavaScript, your favorite browser isn't going to show much of a performance decrease when Strict Mode is enabled for some website (e.g., SunSpider). That is, the performance degrade occurs before code is executed meaning it could be perceptible to end-users but is largely immeasurable using the Date object to measure block execution time
Grabble answered 23/5, 2011 at 21:52 Comment(2)
But how do you know that e.g. v8 doesn't take advantage of strict mode for extra optimisations?Keon
I worked on performance testing Strict Mode for Internet Explorer 10 amongst other things. The best example I can give you is that if you have two identical large JavaScript files with no strict mode violations and only one of them includes "use strict", the one without it will run faster as it's not running the strict mode checks. Just because you remove support for 'with' within strict mode, doesn't mean you can remove it from your parser outright (which still must allow it in non-strict). No, instead your DLL size has actually increased as has your execution time.Grabble

© 2022 - 2024 — McMap. All rights reserved.