6

JavaScript string type is immutable, but does it mean identical strings will share memory?

Say two strings are created in complete different places, will a modern JavaScript engine be smart enough to not double the amount of memory for each "copy" and just re-use the one already created (that exists somewhere in memory)?

Say we got:

var foo = sha256(fooInput); 
//  ... somewhere else
var bar = sha256(barInput);

// Say foo and bar is identical: "foo === bar" => true
// Would they share memory? 

Does it make any difference if the string value is a key in objects? Example:

var cars = {
  "john": {
    // information about all cars "john" owns.
  }
};

var computers = {
  "john": {
    // information about all computers "john" owns.
  }
};

var phones = {
  "john": {
    // information about all phones "john" owns.
  }
};

Will the string "john" in the example above take up memory of three or one string of "john"?

7

The process of sharing strings in this manner is called String Interning, and yes, Javascript does it. The way in which string interning is accomplished in Javascript is an implementation detail, and it varies between different Javascript implementations.

From a performance perspective, you probably shouldn't be worrying about this unless it becomes a significant problem affecting your application that you have specifically identified with a profiling tool.

  • 4
    Nitpick: if it's an implementation detail and varies between different implementations, then, no JavaScript doesn't do it. Some JavaScript implementations may or may not do it to some degree or other, but there is no guarantee. This is like saying that "Java does TCO, it's an implementation detail, and it varies between different implementations, but yes, Java does it." – Jörg W Mittag Jul 27 '16 at 0:19
  • @JörgWMittag: Seems like a distinction without a difference. – Robert Harvey Jul 27 '16 at 14:50
  • 1
    Personally, I believe the distinction between a language feature that is guaranteed by the language spec, and a private internal implementation detail of an implementation that may change any time without notice and may or may not exist on other implementations, and if it even exists at all may or may not behave the way you expect, is a big difference. Especially in JavaScript, where you have pretty much no control over the implementation that your code is going to run in. – Jörg W Mittag Jul 27 '16 at 16:01
  • @JörgWMittag: I guess my point is that only software developers would see my "yes, Javascript does this" statement, and interpret it as a mandate. If most, or all, implementations do it, then Javascript most certainly does it. It may not do it on a train, it may not do it on a plane, but Javascript does exhibit this behavior in some form in all of its implementations. – Robert Harvey Jul 27 '16 at 16:02
1

Short answer: sometimes yes, sometimes no.

I also stumbled upon the same question and looked a bit into it. It seems that interning is done usually for string primitives that are generated the same way (eg. always assigning the same string to a variable in the same loop), BUT I was also able to create an example which results in two identical strings being created with two different references:

enter image description here

As you can see, each string is stored twice, having different references.

This is the code I used to generate the duplicate strings:

const a = [];
const b = [];

for(let j  =1; j<= 100;++j){
    for(let i = 1; i <= 10000; ++i) a[i] = 'player 1 got 5 points from player 2' + i;
    const c = '1';
    for(let i = 2; i <= 20000; ++i) b[i] = 'player 1 got 5 points from player 2' + (i/2 | 0);
}
  • How were you able to see the memory address? – Sunny R Gupta Jan 14 at 17:24
  • 1
    @SunnyRGupta You can take a memory heap snapshot in the dev console. – Cristy Jan 14 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.