0

Using Debian 8, the latest version of Chrome (Chromium) available from the standard repositories is 57. I've been doing some very simple speed tests and obtaining strange results.

When I run the following one-liner in the Console, it completes in about 1 second:

var a = 0;for (var i = 0; i < 10000000; i++) {a = Math.sqrt(33 * Math.random());}console.log(a);

But if I create a button with an onclick handler containing the same code, execution takes more than 15 seconds:

<button onclick="var a = 0;for (var i = 0; i < 10000000; i++) {a = Math.sqrt(33 * Math.random());}console.log(a);">Test</button>

Can anyone shed some light on why this is?

EDIT:

If I separate the code out into a function in a script tag, and reference that function in the button onclick handler, it works as fast as in the Console, a little faster actually.

Theo d'Or
  • 783
  • 1
  • 4
  • 17
  • @JonasW. That inline Javascript is a bad idea is generally accepted, but as far as I know for different reasons than speed of execution (more to do with separation of concerns, control versus presentation). I'm intrigued why inline is so much slower. – Theo d'Or Nov 18 '17 at 16:03
  • 2
    Especially V8 focused its performance improvement on "every day code", so they took some popular webpages and tried to make them load as fast as possible. This results in weird optimizations, in some V8 versions `.forEach` was faster than a `for` loop. So to summarize: if you will behave like the crowd your code will run fast, if you do some special stuff (like inline js) it will run slow because no one put the effoet into optimizing as its not worth it. – Jonas Wilms Nov 18 '17 at 16:07
  • 1
    If i am not mistaken, inline js has to be eval'ed, hence it running slower. Test the code in an actual eval() call and see if you get the same results – Patrick Evans Nov 18 '17 at 16:08
  • I'm curious why anyone could even care how slow inline code is of how they would have come across this situation. It's not 1995 anymore. – JLRishe Nov 18 '17 at 16:08
  • 1
    basically, because that's not code but a String that has to be `eval`d – Thomas Nov 18 '17 at 16:12
  • @JLRishe The way I got to this was by starting testing in Firefox 52, where the Console is as slow as inline. I then tried Chrome and found the difference between inline and Console. You're right, it's not 1995 any more, but knowing how browsers work is a good thing. This might be something you know about well, but I didn't know that inline is a string that must be eval'd, and the rest of the optimization detail as told by Jonas W. – Theo d'Or Nov 18 '17 at 17:35
  • @JonasW. Why did you delete your first comment after my response was posted, orphaning the response? Your second comment about optimization sounds credible though. If you write it up as an answer I'll accept it. – Theo d'Or Nov 18 '17 at 17:38
  • @theo i swear i did not delete it... – Jonas Wilms Nov 18 '17 at 23:45

1 Answers1

1

Especially V8 focused its performance improvement on "every day code", so they took some popular webpages and tried to make them load as fast as possible. That means: if you will behave like the crowd your code will run fast, if you do some special stuff (like inline js) it will run slow because no one put the effort into optimizing as its not worth it.

More information can be found on the V8 GitHub wiki (albeit out of date), while their benchmarks README specifically mentions 50 popular pages that were tested.

Theo d'Or
  • 783
  • 1
  • 4
  • 17
Jonas Wilms
  • 132,000
  • 20
  • 149
  • 151
  • Thanks, Jonas. I've edited your answer to make it acceptable, adding links to V8 on GitHub that I have found in the meantime. – Theo d'Or Nov 19 '17 at 13:16