2

I'm looking into the speed of JavaScript parsers in web browsers, importantly it needs to be easy to demonstrate. I came up with a simple test - the idea being that each script block is parsed and executed individually, so a large block of script could be timed:

<script>var start = new Date().getTime();</script>

<script>
    /*! jQuery v1.8.2 jquery.com | jquery.org/license */
    ...
</script>

<script>alert ( new Date().getTime() - start );</script>

Superficially this appears to work, removing the middle script block will result in a negligible time.

However I'm not certain that my logic is not fundamentally flawed.

i_like_robots
  • 2,760
  • 2
  • 19
  • 23
  • Aside, but you may find it interesting to browse through the strategies employed by some of the performance tests submitted to JSPerf: http://jsperf.com/browse – rjz Oct 22 '12 at 16:14
  • 1
    You'll get an idea of timing on this, but don't forget the cache's effect on load and parse times. If the browser has seen a script before, it may cache the compiled code. Also, you're not the first person to be curious about parse speeds. http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-load.html – Heretic Monkey Oct 22 '12 at 17:34
  • I use JSPerf regularly but I haven't thought of a way to implement this appropriately on there. You're right for pointing out it's a great resource. @MikeMcCaughan If simply hitting refresh on the document it makes a huge difference, I quickly caveated that this must only be done with caching disabled or in a fresh environment. – i_like_robots Oct 22 '12 at 17:59
  • 1
    @i_like_robots; Here I'm referring to the JavaScript engine caching compiled versions of the code, not to browser page caching. See the following answer for a much better overview: http://stackoverflow.com/questions/1096907/do-browsers-parse-javascript-on-every-page-load – Heretic Monkey Oct 22 '12 at 18:10

5 Answers5

1

It seems the answer is broadly yes, but to get a reasonable result (like anything else) the test should be run many times to level out the effects of compilation caching and garbage collection. The test above can easily be placed into the Parse-n-Load library: http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-load.html

Thanks for your help

i_like_robots
  • 2,760
  • 2
  • 19
  • 23
0

This may be of help!

var start = new Date().getTime();
var end = new Date().getTime();
var time = end - start;
alert('Execution time: ' + time);
topcat3
  • 2,561
  • 6
  • 33
  • 57
0

If you want to benchmark your JavaScript, include MilliSeconds etc.

var t = new Date();
var start = t.getTime()*1000 + t.getMilliseconds();

/* do something*/

var t2 = new Date();
var end = t2.getTime()*1000 + t.getMilliseconds();

alert("The Code needed " + (end-start) + " milliseconds. That are " + parseInt((end-start)/1000) + " seconds.");
tobspr
  • 8,200
  • 5
  • 33
  • 46
  • I'm not sure how this is different to what I am already doing, the getTime() method already returns milliseconds. But thank you for pointing out the getMilliseconds() method, it might be useful. – i_like_robots Oct 22 '12 at 16:48
0

You might want to differentiate between parsing and execution time. You could do something like

<script>start = Date.now();</script>
<script>
    parsed = Date.now();
    /*! jQuery v1.8.2 jquery.com | jquery.org/license */
    …
</script>
<script>var end = Date.now();
   alert ( "parsed in " + (parsed - start) + "ms" );
   alert ( "executed in " + (end - parsed) + "ms" );
   alert ( "overall time: " + (end - start) + "ms" );
</script>

With that you might be able to detect cached parse trees etc. Yet, for more distinct information have a look at your developer tools, they show such type of information in their profiler section. Or in Opera, it's included in the load process of scripts in the network panel.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
0

This answer is from 10 years in the future.

There are a number of approaches to timing web page processes including:

  1. Date-related methods:
    • Date.now();

and:

  1. console.time-related methods:
    • console.time('myTimer');
    • console.timeLog('myTimer');
    • console.timeEnd('myTimer');

but, since late 2015, the ideal way to time web page processes using high-resolution timestamps has been:

  • window.performance.now();

Using Performance:

The Performance interface, accessed via window.performance has numerous methods, including:

  • timeOrigin
  • mark
  • measure
  • getEntries
  • toJSON

and more.

But in order to time a script, all you need is window.performance.now():

let scriptStart = window.performance.now();
let scriptEnd = window.performance.now();
let scriptDuration = (scriptEnd - scriptStart);

Working Example:

let paragraph = document.querySelector('p');
let button = document.querySelector('button');

const runTimedScript = () => {

  let scriptStart = window.performance.now();

  for (let i = 0; i < 10000; i++) {
    paragraph.textContent = 'Loop iteration ' + (i + 1);
  }

  let scriptEnd = window.performance.now();

  let scriptDuration = (scriptEnd - scriptStart);
  
  button.textContent = 'Re-run Script';

  console.log('The script ran in ' + scriptDuration + ' milliseconds');
}
  
button.addEventListener('click', runTimedScript, false);
button {
  cursor: pointer;
}
<p></p>
<button type="button">Run Script</button>
<p>To see how long the script takes to run,<br />
click the button above repeatedly.</p>

Further Reading:

To find out more about the Performance Interface, see:

Rounin
  • 27,134
  • 9
  • 83
  • 108