Intermediary variables - what's the performance cost?

Question

const scrollPercent = getScrollPercent();
const mainDivHeight = (mainDivRef.current as any).offsetHeight;
const imgHeight = (imgRef.current as any).offsetHeight;

const offset = ((imgHeight - mainDivHeight) * scrollPercent) / 100;

setBgrImgStyle(x =>
    Object.assign({}, x, { transform: `translateY(-${offset}px)` })
);

As seen, we've got a lot of const declared that are used only once, meaning they could be simply inlined.

I do it frequently to improve readability, sometimes perhaps a too much.

What's the performance cost? The code above is JS, nevertheless I'd be happy to receive a language-agnostic answer.

I would recommend not worrying about it at all. The runtime optimization can figure out when a variable is just a holding spot and optimize it away. Write code that looks the way you want it to look. — Pointy, Nov 01 '19 at 17:35
Sure they can. Modern JavaScript runtimes in particular are insanely sophisticated. — Pointy, Nov 01 '19 at 17:38
Well to be fair there are certain contexts that effectively make optimizations like that impossible. `try catch` is an example that, due to the semantics, may cause the runtime to skip all optimizations because it can't do any of them safely. Most of the time that's not a problem however. — Pointy, Nov 01 '19 at 17:40
You should read about [JIT](https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/). Yes, JS is an interpreted language, but there is so much more to it now. — zero298, Nov 01 '19 at 17:45
It's very likely nil even if running this code in the browser and, even if it wasn't, these expressions can be inlined by the JIT. Declaring an intermediate variable doesn't really have an impact, especially if that variable doesn't actually produce a value and instead points to another one. — Dan, Nov 01 '19 at 18:02
Read this as well https://javascript.info/garbage-collection Also on different engines garbage collection strategies, if you want to really learn. Otherwise, what you have written should not be a concern. — aksappy, Nov 01 '19 at 18:02

score 1 · Answer 1 · answered Nov 01 '19 at 17:58

Don't worry about small performance gains until the operation gets placed in a procedure that gets called hundreds of thousands of times in a loop. Until then, focus on code clarity. If something doesn't happen thousands of times, it's not a problem. Perhaps you could use https://jsperf.com though if you really care.

score 1 · Accepted Answer · answered Nov 01 '19 at 18:26

In the real modern world?

Probably none.

Most applications will pack the JS anyway, and uglify it. If you aren't doing this you should because it reduces your payload, and has the added benefit of making your example not really matter.

A short example:

var get = function(information){
   var name = information.Name;

   if (name == 'john'){var get=function(n){if("john"==n.Name)return!1};
     return false;
   }    
}

is reduced to:

var get=function(n){if("john"==n.Name){return!1}};

If all you are doing is making more readable code, Webpack / uglification or whatever else will likely see this and make the required adjustments for you.

So worry about readable, functional code. Worry about performance when you find an actual problem with performance.

Intermediary variables - what's the performance cost?

2 Answers2