How do you performance test JavaScript code?

Question

CPU Cycles, Memory Usage, Execution Time, etc.?

Added: Is there a quantitative way of testing performance in JavaScript besides just perception of how fast the code runs?

Polish

You might like to look at the YSlow plugin for Firefox. – Bury

That's only going to tell you how long it takes to load. I think the question was more concerned with performance when it is running. – Asterism

For quick and easy tests in your browser you could use jsben.ch – Apperception

Answer 1

Profilers are definitely a good way to get numbers, but in my experience, perceived performance is all that matters to the user/client. For example, we had a project with an Ext accordion that expanded to show some data and then a few nested Ext grids. Everything was actually rendering pretty fast, no single operation took a long time, there was just a lot of information being rendered all at once, so it felt slow to the user.

We 'fixed' this, not by switching to a faster component, or optimizing some method, but by rendering the data first, then rendering the grids with a setTimeout. So, the information appeared first, then the grids would pop into place a second later. Overall, it took slightly more processing time to do it that way, but to the user, the perceived performance was improved.

---

These days, the Chrome profiler and other tools are universally available and easy to use, as are
console.time() (mozilla-docs, chrome-docs)
console.profile() (mozilla-docs, chrome-docs)
performance.now() (mozilla-docs)
Chrome also gives you a timeline view which can show you what is killing your frame rate, where the user might be waiting, etc.

Finding documentation for all these tools is really easy, you don't need an SO answer for that. 7 years later, I'll still repeat the advice of my original answer and point out that you can have slow code run forever where a user won't notice it, and pretty fast code running where they do, and they will complain about the pretty fast code not being fast enough. Or that your request to your server API took 220ms. Or something else like that. The point remains that if you take a profiler out and go looking for work to do, you will find it, but it may not be the work your users need.

Cota

It's a fine tune step after the well known good performant algorithms are in place. – Ixtle

This is a really good answer, in that it takes a practical approach to most situations which the question describes. However, it does not answer the question, which is asking if there's another way to measure this other than just user perception. The entire downtime, such as when the buttons are frozen, can still be measured using the methods in pramodc's answer and the comments attached to it. – Wayzgoose

Answer 2

I do agree that perceived performance is really all that matters. But sometimes I just want to find out which method of doing something is faster. Sometimes the difference is HUGE and worth knowing.

You could just use javascript timers. But I typically get much more consistent results using the native Chrome (now also in Firefox and Safari) devTool methods console.time() & console.timeEnd()

Example of how I use it:

var iterations = 1000000;
console.time('Function #1');
for(var i = 0; i < iterations; i++ ){
    functionOne();
};
console.timeEnd('Function #1')

console.time('Function #2');
for(var i = 0; i < iterations; i++ ){
    functionTwo();
};
console.timeEnd('Function #2')

Update (4/4/2016):

Chrome canary recently added Line Level Profiling the dev tools sources tab which let's you see exactly how long each line took to execute!

Grove

Yes, one of the charms with this one is that it's fast n easy to implement. I wonder, will the logging per se take some of the performance from the javascript execution. Let's say that we have a loop in a game and it outputs multiple log rows. For example once per second for 5 minutes, that is 300 rows. Anyone knows? – Invocate

Is this still operational? Not appaering in Chrome. – Timmi

Yup still works for me. developer.chrome.com/devtools/docs/console-api#consoletimelabel – Grove

@K.KilianLindberg Logging will always take time from performance, as will any code, but a) it'll be consistent in your tests and b) you shouldn't be console logging in live code. After testing on my machine, time logging is only a fraction of a MS, but it will add up the more you do it. – Leadsman

Answer 3

We can always measure time taken by any function by simple date object.

var start = +new Date();  // log start timestamp
function1();
var end =  +new Date();  // log end timestamp
var diff = end - start;

Sanctimonious

Note that this solution returns the diff in milliseconds – Sequin

Using Date() is discouraged since the time in milliseconds can vary depending on system factors. Instead use console.time() and console.timeEnd(). See answer by JQuery Lover for more details. – Eureka

Even better, use performance.now() – Tonguing

Before use performance.now() please check browser compatibility. developer.mozilla.org/en-US/docs/Web/API/Performance/… – Crystallite

Date isn't really representative of the time that's passed. Check out this article on it: sitepoint.com/measuring-javascript-functions-performance . Performance.now() is a more accurate time stamp. – Hawaiian

Answer 4

Try jsPerf. It's an online javascript performance tool for benchmarking and comparing snippets of code. I use it all the time.

Redeeming

Since jsPerf is down at the moment, benchmarkjs is easy to use instead. – Adena

I also recommend it since it gives a ops/sec measurement (it runs your code multiple times) – Gab

+9001 (that's over nine thousand ;) for jsPerf. I regularly use this in a similar manner to %timeit in an ipython REPL shell for Python code. – Tangle

Unfortunately it looks like this is no longer available :( – Knickers

Answer 5

Most browsers are now implementing high resolution timing in performance.now(). It's superior to new Date() for performance testing because it operates independently from the system clock.

Usage

var start = performance.now();

// code being timed...

var duration = performance.now() - start;

References

• https://developer.mozilla.org/en-US/docs/Web/API/Performance.now()
• http://www.w3.org/TR/hr-time/#dom-performance-now

Expugnable

Even better would be to use the User Timing API, which builds upon performance.now(). – Teresita

Answer 6

JSLitmus is a lightweight tool for creating ad-hoc JavaScript benchmark tests

Let examine the performance between function expression and function constructor:

<script src="JSLitmus.js"></script>
<script>

JSLitmus.test("new Function ... ", function() { 
    return new Function("for(var i=0; i<100; i++) {}"); 
});

JSLitmus.test("function() ...", function() { 
       return (function() { for(var i=0; i<100; i++) {}  });
});

</script>

What I did above is create a function expression and function constructor performing same operation. The result is as follows:

FireFox Performance Result

IE Performance Result

Rostrum

The linked JSLitmus page contains broken download links. I've found JSLitmus (for browsers) and jslitmus (for NodeJS, lowercase!). – Quita

Answer 7

Some people are suggesting specific plug-ins and/or browsers. I would not because they're only really useful for that one platform; a test run on Firefox will not translate accurately to IE7. Considering 99.999999% of sites have more than one browser visit them, you need to check performance on all the popular platforms.

My suggestion would be to keep this in the JS. Create a benchmarking page with all your JS test on and time the execution. You could even have it AJAX-post the results back to you to keep it fully automated.

Then just rinse and repeat over different platforms.

Destruction

this is true, but profilers are good in case there is a coding problem that has nothing to do with a browser specific issue. – Osullivan

Sure! Yeah they'll catch general "bad coding" problems and specific ones are great for doing the actual debugging, but for general use-case testing, you'll benefit from something that runs on all platforms. – Destruction

+1 on the note that this is true, but having a profiler like Firebug is still great, if not essential, to find bottlenecks. – Tineid

"Considering 99.999999% of sites…" I think you made that up… :-/ – Vend

@Vend I might be overstating a decimal place or two, but the idea that your development platform probably isn't going to be identical to your deployment platform holds. – Destruction

Answer 8

Here is a simple function that displays the execution time of a passed in function:

var perf = function(testName, fn) {
    var startTime = new Date().getTime();
    fn();
    var endTime = new Date().getTime();
    console.log(testName + ": " + (endTime - startTime) + "ms");
}

Kirkham

Answer 9

I have a small tool where I can quickly run small test-cases in the browser and immediately get the results:

JavaScript Speed Test

You can play with code and find out which technique is better in the tested browser.

Tacnaarica

Thanks, this is just what I was looking for. – Cumine

Answer 10

I think JavaScript performance (time) testing is quite enough. I found a very handy article about JavaScript performance testing here.

Magazine

Answer 11

You could use this: http://getfirebug.com/js.html. It has a profiler for JavaScript.

Osullivan

Answer 12

I was looking something similar but found this.

https://jsbench.me/

It allows a side to side comparison and you can then also share the results.

Ethnography

Answer 13

performance.mark (Chrome 87 ^)

performance.mark('initSelect - start');
initSelect();
performance.mark('initSelect - end');

Emu

Answer 14

Quick answer

On jQuery (more specifically on Sizzle), we use this (checkout master and open speed/index.html on your browser), which in turn uses benchmark.js. This is used to performance test the library.

Long answer

If the reader doesn't know the difference between benchmark, workload and profilers, first read some performance testing foundations on the "readme 1st" section of spec.org. This is for system testing, but understanding this foundations will help JS perf testing as well. Some highlights:

What is a benchmark?

A benchmark is "a standard of measurement or evaluation" (Webster’s II Dictionary). A computer benchmark is typically a computer program that performs a strictly defined set of operations - a workload - and returns some form of result - a metric - describing how the tested computer performed. Computer benchmark metrics usually measure speed: how fast was the workload completed; or throughput: how many workload units per unit time were completed. Running the same computer benchmark on multiple computers allows a comparison to be made.

Should I benchmark my own application?

Ideally, the best comparison test for systems would be your own application with your own workload. Unfortunately, it is often impractical to get a wide base of reliable, repeatable and comparable measurements for different systems using your own application with your own workload. Problems might include generation of a good test case, confidentiality concerns, difficulty ensuring comparable conditions, time, money, or other constraints.

If not my own application, then what?

You may wish to consider using standardized benchmarks as a reference point. Ideally, a standardized benchmark will be portable, and may already have been run on the platforms that you are interested in. However, before you consider the results you need to be sure that you understand the correlation between your application/computing needs and what the benchmark is measuring. Are the benchmarks similar to the kinds of applications you run? Do the workloads have similar characteristics? Based on your answers to these questions, you can begin to see how the benchmark may approximate your reality.

Note: A standardized benchmark can serve as reference point. Nevertheless, when you are doing vendor or product selection, SPEC does not claim that any standardized benchmark can replace benchmarking your own actual application.

Performance testing JS

Ideally, the best perf test would be using your own application with your own workload switching what you need to test: different libraries, machines, etc.

If this is not feasible (and usually it is not). The first important step: define your workload. It should reflect your application's workload. In this talk, Vyacheslav Egorov talks about shitty workloads you should avoid.

Then, you could use tools like benchmark.js to assist you collect metrics, usually speed or throughput. On Sizzle, we're interested in comparing how fixes or changes affect the systemic performance of the library.

If something is performing really bad, your next step is to look for bottlenecks.

How do I find bottlenecks? Profilers

What is the best way to profile javascript execution?

Ixtle

Answer 15

I find execution time to be the best measure.

Nole

As opposed to what? I'm not sure I understand. – Tineid

As opposed to the orignal posters question: "CPU Cycles, Memory Usage, Execution Time, etc.?" – Politics

CPU Cycles, Memory usage are bad. – Posturize

Answer 16

You could use console.profile in firebug

Tetreault

Answer 17

I usually just test javascript performance, how long script runs. jQuery Lover gave a good article link for testing javascript code performance, but the article only shows how to test how long your javascript code runs. I would also recommend reading article called "5 tips on improving your jQuery code while working with huge data sets".

Peloria

Answer 18

Here is a reusable class for time performance. Example is included in code:

/*
     Help track time lapse - tells you the time difference between each "check()" and since the "start()"

 */
var TimeCapture = function () {
    var start = new Date().getTime();
    var last = start;
    var now = start;
    this.start = function () {
        start = new Date().getTime();
    };
    this.check = function (message) {
        now = (new Date().getTime());
        console.log(message, 'START:', now - start, 'LAST:', now - last);
        last = now;
    };
};

//Example:
var time = new TimeCapture();
//begin tracking time
time.start();
//...do stuff
time.check('say something here')//look at your console for output
//..do more stuff
time.check('say something else')//look at your console for output
//..do more stuff
time.check('say something else one more time')//look at your console for output

Hillegass

Answer 19

UX Profiler approaches this problem from user perspective. It groups all the browser events, network activity etc caused by some user action (click) and takes into consideration all the aspects like latency, timeouts etc.

Serafina

Answer 20

Performance testing became something of a buzzword as of late but that’s not to say that performance testing is not an important process in QA or even after the product has shipped. And while I develop the app I use many different tools, some of them mentioned above like the chrome Profiler I usually look at a SaaS or something opensource that I can get going and forget about it until I get that alert saying that something went belly up.

There are lots of awesome tools that will help you keep an eye on performance without having you jump through hoops just to get some basics alerts set up. Here are a few that I think are worth checking out for yourself.

1. Sematext.com
2. Datadog.com
3. Uptime.com
4. Smartbear.com
5. Solarwinds.com

To try and paint a clearer picture, here is a little tutorial on how to set up monitoring for a react application.

Thermolysis

Answer 21

You could use https://github.com/anywhichway/benchtest which wraps existing Mocha unit tests with performance tests.

Caboose

Answer 22

The golden rule is to NOT under ANY circumstances lock your users browser. After that, I usually look at execution time, followed by memory usage (unless you're doing something crazy, in which case it could be a higher priority).

Timoshenko

Answer 23

This is a very old question but I think we can contribute with a simple solution based on es6 for fast testing your code.

This is a basic bench for execution time. We use performance.now() to improve the accuracy:

/**
 * Figure out how long it takes for a method to execute.
 * 
 * @param {Function} method to test 
 * @param {number} iterations number of executions.
 * @param {Array} list of set of args to pass in. 
 * @param {T} context the context to call the method in.
 * @return {number} the time it took, in milliseconds to execute.
 */
const bench = (method, list, iterations, context) => {
    let start = 0
    const timer = action => {
        const time = performance.now()
        switch (action) {
            case 'start':
                start = time
                return 0
            case 'stop':
                const elapsed = time - start
                start = 0
                return elapsed
            default:
                return time - start
        }
    };

    const result = []
    timer('start')
    list = [...list]
    for (let i = 0; i < iterations; i++) {
      for (const args of list) {
        result.push(method.apply(context, args))
      }
    }
    const elapsed = timer('stop')
    
    console.log(`Called method [${method.name}]
    Mean: ${elapsed / iterations}
    Exec. time: ${elapsed}`)


    return elapsed
}

const fnc = () => {}
const isFunction = (f) => f && f instanceof Function
const isFunctionFaster = (f) => f && 'function' === typeof f


class A {}

function basicFnc(){}
async function asyncFnc(){}

const arrowFnc = ()=> {}
const arrowRFnc = ()=> 1

// Not functions
const obj = {}
const arr = []
const str = 'function'
const bol = true
const num = 1
const a = new A()

const list = [
    [isFunction],
    [basicFnc],
    [arrowFnc],
    [arrowRFnc],
    [asyncFnc],
    [Array],
    [Date],
    [Object],
    [Number],
    [String],
    [Symbol],
    [A],
    [obj],
    [arr],
    [str],
    [bol],
    [num],
    [a],
    [null],
    [undefined],
]


const e1 = bench(isFunction, list, 10000)
const e2 = bench(isFunctionFaster, list, 10000)

const rate = e2/e1
const percent = Math.abs(1 - rate)*100

console.log(`[isFunctionFaster] is ${(percent).toFixed(2)}% ${rate < 1 ? 'faster' : 'slower'} than [isFunction]`)

Algy

Answer 24

This is a good way of collecting performance information for the specific operation.

start = new Date().getTime(); 
for (var n = 0; n < maxCount; n++) {
/* perform the operation to be measured *//
}
elapsed = new Date().getTime() - start;
assert(true,"Measured time: " + elapsed);

Punkah