JavaScript empty object size

Question

What is the memory footprint of an empty object in JavaScript? If object is created using object literal syntax:

let emptyObj = {};

in Google Chrome Developer Tools (Profiles tab), after taking snapshot, it shows that Shallow Size as well as Retained Size is equal to 56 Bytes. Also, the same size is present if object is created by:

let emptyObj = Object.create(null);

For me, that's far too much, as I am creating a lot of objects (not necessarily empty, but mostly with only few properties) during code execution and I have to store them in memory. I am assuming that if it would be possible to decrease empty-object size, it would be also possible to decrease size of an object with properties by the same amount of Bytes.

For example, if object looks like this:

let foo = {bar: 4};

and it has the size of, let's say, 56 (empty object overhead) + 6 (key) + 8 (value) = 70 Bytes, then reducing size of an empty object by 40 Bytes would result foo having size of 30 Bytes (16 + 6 + 8).

Is this correct interpretation of Chrome's empty object size? Is it possible to decrease it? Would it result in decreasing size of not-empty object?

Answer 1

It is not possible to decrease the size of an empty object.

An ordinary object like {}:

• Has overhead that is created by the language implementation, and cannot be managed by ECMAScript language directly.
• Includes essential internal slots: [[PrivateElements]], [[ProtoType]], [[Extensible]]. See OrdinaryObjectCreate in the ECMA Script specification.
• Is associated with essential internal methods: [[GetPrototypeOf]], [[SetPrototypeOf]], [[IsExtensible]], [[PreventExtensions]], [[GetOwnProperty]], [[DefineOwnProperty]], [[HasProperty]], [[Get]], [[Set]], [[Delete]], [[OwnPropertyKeys]]. See Ordinary Object Internal Methods and Internal Slots in the ECMA Script specification.

Note that internal slots and method references are not object properties; they cannot be directly accessed via the ECMA Script language. How they actually are implemented is implementation dependent. As stated by the ECMA Script specification for "ordinary object":

...The exact manner in which this is accomplished is determined by the implementation. [...] internal slots are allocated as part of the process of creating an object and may not be dynamically added to an object. [...] the ECMAScript language provides no direct way to associate internal slots with an object.

The above list of internal slots and internal method associations has 3+11=14 entries. If we imagine an ECMA Script compliant implementation where these values take up 4 bytes each, we arrive at 56 bytes for the minimal footprint of an ECMA Script object.

Maintaining a history of state

From comments it seems your specific context is about maintaining a history of state, so to be able to return to a previous state.

There are a few things you can consider:

• Instead of storing a history of immutable objects, you could define do/undo methods on a single mutable object, only saving the difference. This will add some overhead to the processing. For instance, a chess implementation could store moves and the current board instead of all the boards that were "visited" during a game.

• If the object properties are primitives, you could maintain one array for each property, where the index in these arrays selects the values that belong together. So you would actually store the set of objects in a transposed format. The memory footprint could be further reduced by using typed arrays. This is however an antipattern from the viewpoint of OOP.

• Some data might be stored more efficiently in bitmaps. If these happen to be larger than 32 bits, you could use a BigInt data type, which has support for bit operators.