Safari and Chrome JS execution time: immense difference

I was experimenting with executing javascript code from Construct 3 and noticed something rather strange. A simple JS code is executed 100 times slower than the simplest native Construct instruction. But only in Chrome. In Safari it's the same.

Here's the example project: test.c3p

Safari 11.0.2

— 3,000,000 empty loops: 4.5 sec

— 3,000,000 loops with "System: Set VARIABLE to 666": 8.9 sec

— 3,000,000 loops with "Browser: Execute javascript 'var variable=666'": 8.5 sec

Chrome 63.0.3239.132

— 3,000,000 empty loops: 0.88 sec

— 3,000,000 loops with "System: Set VARIABLE to 666": 1.2 sec

— 30,000 loops with "Browser: Execute javascript 'var variable=666'": 1.65 sec

See? I tested javascript execution in Chrome on 30,000 loops instead of 3,000,000 because otherwise it hangs the browser dead and seems to never execute it.

Same thing when I use my own Javascript plugin that simply does "eval" of a string you pass to it. Is it normal or what?

Ashley any ideas?

This isn't a meaningful test. The JS engine can see that the executed JavaScript will have no effect at all, and just ignore it. However in practice nobody uses JavaScript that has no effect at all, so it's not important if this case is optimised or not. Different browsers will have different approaches.

Anyway, in general executing JS from a string is terrible for performance, because it has to run the string through the whole parse and compile stages of the JS engine before it even starts executing it, and these stages are optimised for loading long scripts (i.e. web page startup). So it's not surprising if parsing a small string of JS has 100x the overhead of running some existing JS code that has probably already reached the top tier of the JIT.

If you want to run custom JS and performance matters, write an addon that uses the code directly and never uses eval.

This isn't a meaningful test. The JS engine can see that the executed JavaScript will have no effect at all, and just ignore it. However in practice nobody uses JavaScript that has no effect at all, so it's not important if this case is optimised or not. Different browsers will have different approaches.

I checked. JS engine doesn't ignore this code and properly executes it. It's easy to check in a console. Just declare a variable that is later altered with the code we're talking about and see in console whether the variable was altered.

And still 100x difference between Chrome and Safari. Can it be not the JS issue then? Maybe it has something to do with the plugin action call itself?

Strings still have to go through the parse and compile stages, which could easily explain the 100x overhead. It's like comparing the difference of running a "mov" CPU instruction vs. compiling and then executing a C program that assigns a single variable, in a tight loop. You are measuring the performance of the compiler, not the language. Whether or not the browser caches the result of a no-op JS string probably explains the difference between browsers, and that is likely to vary between browsers especially since the given string doesn't do anything useful or realistic. Either way, like I said, executing JS from strings is fundamentally a slow thing to do. Don't do it if you care about performance.

Ashley Thanks! That's a good advice. Will try to avoid eval if it's possible.