Are JavaScript’s default parameters slowing me down?

Photo by Markus Spiske on Unsplash

For every software engineer, when writing code, there should be a balance of efficiency, style, and implementation of features. But what happens when the latter takes the precedent over efficiency? Well, the short answer is you have code that looks good but perhaps doesn’t work all that well. Granted when I write code the first thing on my mind is to make it work. Once I’ve crossed that bridge, I look to enhance performance. Let’s take a look at one JavaScript feature and see an example of how it could make your code less performant.

Default Parameters

Default parameters were introduced in ECMAScript2015, what we affectionately call “ES6”. Now, JavaScript being the liberal (dynamic) language that it is, in that sense default parameters are a God send. There are new language features every year and if engineers are careless in their implementation, or inconsiderate of the features they use, they may inadvertently introduce unnecessary latency and/or bugs into their code.

Here is an example of a default parameter in action.

In this simple function we take a value which is a string and log it. This example is over simplified but it does illustrate quite well how default parameters work. Now for that example, a default is fine if we don’t want to perform any “business” logic. But what if we only have one parameter and we want to manipulate that parameter? What if when that parameter is absent, do we want to continue to execute the logic or should we stop early and return a value? Let’s stop and do some benchmarking of the former with just a little more business logic than before.

The first time that code runs you may see something like the following in the console: withDefault: 0.218ms. Subsequent runs of the same code may be “slightly” faster (or not!). 0.577ms was my worst time and 0.181ms was my best time when running this code in Node v12.6.0.

I take exception to this, to this style of coding. I ask myself, what if when this function is called s is equal to undefined? Should we even attempt to run the rest of the code? I answer to myself, no. If s is equal to undefined we should return a value immediately (because we’re doing so eventually). When s is undefined, in this case, we should just stop all action by returning an empty string ('').I mean that’s where we’re headed anyway. Let’s take a look at another example where we terminate early.

When I run this code it consistently runs between 0.023ms and 0.029ms. Comparing the worst times of both functions, 0.522/0.029, withoutDefault runs 18Xs faster. Wow! Comparing our best times, 0.181/0.023, the more verbose code ran 8Xs faster (7.86… rounded up). The more verbose code wins.

Aside from the fact that it’s faster, this code is more explicit. What I mean by that is that we are handling our exception and explicitly returning the value we want. There isn’t anything implied as in the case of withDefault. Another benefit of going with withoutDefault is that we’re not running code unnecessarily. In withDefault we are still performing, to some extent, every operation just to return an empty string — time waster! Now imagine that you have an application of 10K, 20K, 120K lines of code. If your pattern is to always resort to a default param and omit early termination, you could seriously be missing out on the performance benefits of more explicit and early terminating code.

In Summary:

If you are one of those developers that will always advocate for the “elegant” solution, remember that the elegance you strive for may not be worth the cost you pay in slower code. 🙃

Enjoy your Holiday!

Cloud Engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store