Comparison of various ways to measure the performance of JavaScript functions

Overview

Measuring the time it takes to execute a function is always a good way to prove that some implementations perform better than another. This is also a good way to ensure that performance has not been affected after some changes, and to track down bottlenecks.

Good performance contributes to a good user experience, and a good user experience keeps users coming back. One study showed that 88% of online consumers are less likely to return after a poor user experience due to performance issues.

That's why it's possible to identify bottlenecks in your code and measure improvements. Especially when developing JavaScript for browsers, be aware that every line of JavaScript you write has the potential to block the DOM since it is a single-threaded language.

In this post I’ll explain how you can measure the performance of your functions, and what to do with the results you get from them.

Performance.now

The performance API provides access to DOMHighResTimeStamps through its function performance.now(), which returns the time elapsed in milliseconds since the page was loaded, with a precision of up to fractions of 5μs.

So in practice, you need to take two timestamps, store them in a variable, and then subtract the first from the second timestamp.

const t0 = performance.now();
for (let i = 0; i < array.length; i++) {
  //some code
}
const t1 = performance.now();
console.log(t1 - t0, 'milliseconds');

Chrome Output

0.6350000001020817 "milliseconds"

Firefox Output

1 milliseconds

Here we can see that the results in Firefox are completely different from Chrome, this is because Firefox version 60 has reduced the precision of the performance API to 2ms.

The performance API provides much more functionality than just returning a timestamp; it can measure navigation timing, user timing, or resource timing. Please see this article for a more detailed explanation.

However, for our use case, we only want to measure the performance of a single function, so a timestamp is sufficient.

Isn't that the same as Date.now?

Now you might be thinking: I could also do this with Date.now.

Yes, you can, but there are drawbacks.

Date.now returns the time in milliseconds since the Unix epoch ("1970-01-01-01T00:00:00:00Z") and depends on the system clock. Not only does this mean it's not as precise, but it also won't necessarily be increasing. WebKit engineer (Tony Gentilcore) explained it like this:

Perhaps less considered, Date based on the system time is also not ideal for true user monitoring. Most systems run a daemon that synchronizes the time periodically. Typically, the clock is adjusted by a few milliseconds every 15-20 minutes. At this rate, about 1% of the 10-second intervals are inaccurate.

Console.time

The API is really easy to use, just put console.time in front of the code you want to measure and console.timeEnd after the code you want to measure, call the function with the same string parameter, and you can use up to 10,000 timers on a page at the same time.

The precision is the same as the performance API, but this is again browser dependent.

console.time('test');
for (let i = 0; i < array.length; i++) {
  //some code
}
console.timeEnd('test');

This will automatically generate human-readable output, as shown below:

Chrome Output

test: 0.766845703125ms

Firefox Output

test: 2ms - timer ended

The output here is again very similar to the Performance API.

The advantage of console.time is that it is easy to use, as it does not require manually calculating the difference between two timestamps.

Shorten time accuracy

If you measure your functions using the APIs mentioned above in different browsers, you may find that the results vary.

This is due to the browser trying to protect users from timing attacks and fingerprinting attacks; if the timestamp is too accurate, a hacker could use it to identify the user.

For example, browsers like Firefox try to prevent this by reducing the precision to 2ms (version 60).

Things to note

Now you have the tools you need to measure the speed of your JavaScript functions. However, there are some pitfalls that are best avoided.

Divide and conquer

You notice that something is slow when filtering some results, but you don’t know where the bottleneck is.

Rather than guessing which part of your code is slow, use these functions to measure it.

To track it down, first put your console.time statements around the slow block of code. Then measure how different parts of them perform, and if one part is slower than the others, keep going down that path, going deeper there each time, until you find the bottleneck.

The less code there is between these statements, the less likely you are to track something you're not interested in.

Note the input value

In real applications, the input values ​​of a given function may vary greatly. Measuring the speed of a function simply for arbitrary random values ​​doesn't provide any valuable data that we can actually use.

Make sure to run the code with the same input values.

Running a function multiple times

Suppose you have a function that iterates over an array, performs some calculation on each array value, and returns an array of the results. You want to know whether forEach or a simple for loop is more efficient.

Here is the function:

function testForEach(x) {
  console.time('test-forEach');
  const res = [];
  x.forEach((value, index) => {
    res.push(value / 1.2 * 0.1);
  });

  console.timeEnd('test-forEach')
  return res;
}

function testFor(x) {
  console.time('test-for');
  const res = [];
  for (let i = 0; i < x.length; i ++) {
    res.push(x[i] / 1.2 * 0.1);
  }

  console.timeEnd('test-for')
  return res;
}

You can test them like this:

const x = new Array(100000).fill(Math.random());
testForEach(x);
testFor(x);

If you run the above function in Firefox, you will get output similar to the following:

test-forEach: 27ms - timer ended

test-for: 3ms - timer ended

It looks like forEach is slow, right?

Let's see if we run the same function twice with the same input:

testForEach(x);

testForEach(x);

testFor(x);

testFor(x);

test-forEach: 13ms - timer ended

test-forEach: 2ms - timer ended

test-for: 1ms - timer ended

test-for: 3ms - timer ended

If we call forEach test a second time, it performs just as well as the for loop. Given the slow initial value, it's probably not worth using forEach anyway.

...in multiple browsers

If we run the above code in Chrome, the results suddenly look different:

test-forEach: 6.156005859375ms

test-forEach: 8.01416015625ms

test-for: 4.371337890625ms

test-for: 4.31298828125ms

This is because Chrome and Firefox have different JavaScript engines with different types of performance optimizations. It's good to be aware of these differences.

In this case, Firefox optimizes the use of forEach better for the same input.

for performs better on both engines, so it's best to stick with the for loop.

This is a good example of why you should measure in multiple engines. If you measure using only Chrome, you might conclude that forEach isn't that bad compared to for.

Throttling Your CPU

These numbers don't look high. Be aware that your development machine will usually be much faster than the average mobile phone your website will be viewed on.

To get a feel for what this looks like, browsers have a feature that allows you to throttle your CPU performance.

With this, those 10 or 50ms quickly turned into 500ms.

Measuring relative performance

These raw results actually depend not only on your hardware, but also on your CPU and the current load of your JavaScript thread. Try to focus on the relative improvements in your measurements, because the numbers may look very different the next time you restart your PC.

Summarize

In this article, we saw some JavaScript APIs that we can use to measure performance, and how to use them in the “real world”. For simple measurements I find it easier to use console.time.

I feel like a lot of front-end developers don’t give enough thought to performance on a daily basis, even though it has a direct impact on revenue.

The above is the detailed content of the comparison of various methods of measuring the performance of JavaScript functions. For more information about JavaScript function performance, please pay attention to other related articles on 123WORDPRESS.COM!