`Map.prototype.size` is O(n)

Why is the size accessor O(n)? It can easily be O(1) as you explicitly know when set or delete is called. Also please don’t make calcSize O(n) in set/delete as you can just use a simple increment or decrement as necessary.

[dcherman]

@Gheoan As pointed out on the mailing list,

http://www.ecma-international.org/ecma-262/7.0/index.html#sec-map-objects

The data structures used in this Map objects specification is only intended to describe the required observable semantics of Map objects. It is not intended to be a viable implementation model

The semantics surrounding size are clearly described, but we don’t need to follow the spec to the letter (per the spec itself) so long as we follow the same semantics. With that in mind, I think this is a valid issue as we can reliably make the size accessor much faster.

[dcherman]

Wow, TIL.

If you don’t mind leaving this open in the short term, I’ve posted a question to esdiscuss to get clarification about why the spec is the way that it is since requiring this work to get done each time on get size was incredibly surprising to me.

Will follow up when I get a response.