In JavaScript What's the difference between variable having value and passing that value directly

Viewed 175

I'm new to development, just need to know in terms of memory does it matter using a value without assigning in to a variable

Example 1:

var sendResponse = {
    "a": 1,
    "b": 2
};
res.send(sendResponse);

OR

res.send({
    "a": 1,
    "b": 2
});

Example 2:

var valueOne = "hi";
var valueTwo = "hithere";

    if (someVariable  == valueOne  || someVariable == valueTwo) {
        //
    }

    OR

    if (someVariable  == "hithere" || someVariable == "hi") {
        //
    }

Example 3:

var concatOne = "hi";
    var concatTwo = "hithere";

    var concatString = concatOne + concatTwo;

    OR

    var concatString = "hi" + "hithere";
2 Answers

Short answer:

It doesn't matter.

Cop-out answer:

What you're asking is basically the JavaScript equivalent of "How much memory does an rvalue take?" in C++, which has a good answer here.

Longer answer:

If you absolutely care about memory usage and performance then you shouldn't be using JavaScript in the first place (yes, modern JS JITs are very fast and are fast-approaching traditional AOT-compiled languages like C++, but there's still a huge memory tradeoff and first-run performance-hit for the JIT).

Secondarily, the kind of optimization you're referring to is a microoptimization - even if there are savings to be made by putting string-literals directly as arguments it would maybe save you maybe a handful of bytes for the entire script execution, compare that to the tens-to-hundreds of megabytes of memory that V8 will happily use (and that's still a fraction of the presumably dozens of gigabytes of RAM that your computer has).


(The technical details below are generalities and are not specific to V8 - which I'm not intimately familiar with, though I do have first-hand experience with the internals of Chakra from my time at Microsoft).

Some things to consider:

  • Most importantly: the JavaScript specification does not dictate how a JS engine is implemented. Someone could build a horribly inefficient engine that uses a gigabyte of internal memory for each variable and still comply with the spec. To give a perfect answer to your question would require a through and in-depth knowledge of V8's internals - and such knowledge would be outdated and obsolete within a few years anyway given how fast the JS ecosystem changes.

  • Most modern JavaScript engines (including V8) generally have 3 modes of operation:

    1. Parsing.
    2. Interpreted mode.
    3. JIT mode.
  • Before a script can be executed it needs to be parsed: and when a script is being parsed any string-literals will be interned and kept in read-only memory (and so the string values consume a fixed, known, quantity of memory), which means that those values will never be destroyed by the GC.

    • Side-note: some systems (like Win32 and Prolog) refer to these as "string atoms" or "atomic strings" instead of "interned strings", with subtly different semantics.
    • (I accept that string-literals in dynamically evaluated scripts (namely in eval()) may be reclaimed - however I don't believe (but I could easily be wrong!) that any JS engines' GC today will free string literals that have no references pointing at them.
  • After a string literal has been interned it's possible for a JS engine's user-script variables to use some internal tagged reference type to succinctly refer to the string without needing to use a full 8-byte internal pointer (similar to, but not exactly nor necessarily a tagged pointer), there is also the possibility for small-string-optimization to be used (where a local copy of the entire string, if it's small enough, is used instead of a pointer or reference to the string - this is fairly commonplace in C++ to avoid the runtime costs of multiple indirection).

  • Don't conflate memory used by a reference or local to the memory used by the value.

    • Memory usage by references/locals is difficult to identify because any fairly decent JIT will perform a lot of operations entirely within CPU registers and other non-memory addresses - as well as predetermining many operations as though they were like C++ constexpr - so if a variable is elided away does it still use any memory? does it use "zero" bytes? that's more a philosophical question, imo.
  • (there's loads more I could write on this subject but it's 7am now and I'm off...)

Yes it does, Because when you declare a variable in JS we are not specifying the size that variable going to hold so it allocates a minimal space for every variable we create , as well as the names we give to every variable will also take some space. So in case of dynamic allocation its okay do that , But the second method in every example is the preferred one.

var concatOne = "hi";
var concatTwo = "hithere";

var concatString = concatOne + concatTwo;

here the "var" keywords does not know which data type your going to use so it will be allocated the most heights data type size like big int , and also the two variable names also holds some space.

But the another method is priffered to be a good practice with optimized memory use as well as shorter code size, which can improve your code working performance the compilation and run time will be considerably lower

  var concatString = "hi" + "hithere";
Related