Will console.log reduce JavaScript execution performance?

Will use of the debugging feature console.log reduce JavaScript execution performance? Will it affect the speed of script execution in production environments?

Is there an approach to disable console logs in production environments from a single configuration location?

Actually, console.log is a lot slower than an empty function. Running this jsPerf test on my Chrome 38 gives stunning results:

• when the browser console is closed, calling console.log is about 10 000 times slower than calling an empty function,
• and when the console is open, calling it is as much as 100 000 times slower.

Not that you'll notice the performance lag if you have a reasonable number of console.… calls firing once (a hundred will take 2 ms on my install of Chrome – or 20 ms when the console is open). But if you log stuff to the console repeatedly – for instance, hooking it up through requestAnimationFrame – it can make things janky.

Update:

In this test I've also checked out the idea of a custom “hidden log” for production – having a variable which holds log messages, available on demand. It turns out to be

• about 1 000 times faster than the native console.log,
• and obviously 10 000 times faster if the user has his console open.

If you are going to have this on a public site or something, anyone with little knowledge on using the developer tools can read your debug messages. Depending on what you are logging, this may not be a desirable behavior.

One of the best approaches is to wrap the console.log in one of your methods, and where you can check for conditions and execute it. In a production build, you can avoid having these functions. This Stack Overflow question talks in details about how to do the same using the Closure compiler.

So, to answer your questions:

1. Yes, it will reduce the speed, though only negligibly.
2. But, don't use it as it's too easy for a person to read your logs.
3. The answers to this question may give you hints on how to remove them from production.

const DEBUG = true / false
DEBUG && console.log('string')

> Will use of the debugging feature console.log reduce JavaScript > execution performance? Will it affect the speed of script execution in > production environments?

Of course, console.log() will reduce your program's performance since it takes computational time.

> Is there an approach to disable console logs in production > environments from a single configuration location?

Put this code at the beginning of your script to override the standard console.log function to an empty function.

console.log = function () { };

If you create a shortcut to the console in a common core script, eg:

var con = console;

and then use con.log("message") or con.error("error message") throughout your code, on production you can simply rewire con in the core location to:

var con = {
	log: function() {},
	error: function() {},
	debug: function() {}
}

Any function call will slightly reduce performance. But a few console.log's should not have any noticeable effect.

However it will throw undefined errors in older browsers that don't support console

The performance hit will be minimal, however in older browsers it will cause JavaScript errors if the users browsers console is not open log is not a function of undefined. This means all JavaScript code after the console.log call will not execute.

You can create a wrapper to check if window.console is a valid object, and then call console.log in the wrapper. Something simple like this would work:

window.log = (function(console) {
    var canLog = !!console;
    return function(txt) {
        if(canLog) console.log('log: ' + txt);
    };
})(window.console);

log('my message'); //log: my message

Here is a fiddle: http://jsfiddle.net/enDDV/

I made this jsPerf test: http://jsperf.com/console-log1337

It doesn't seem to take any longer than other function calls.

What about browsers that doesn't have a console API? If you need to use console.log for debugging, you might include a script in your production deployment to override the console API, like Paul suggests in his answer.

I do it this way to maintain original signature of console methods. In a common location, loaded before any other JS:

var DEBUG = false; // or true 

Then throughout code

if (DEBUG) console.log("message", obj, "etc");
if (DEBUG) console.warn("something is not right", obj, "etc");