Map/Set.prototype.size is O(n)
# MichaĆ Wadas (8 years ago)
Implementations aren't required to follow exactly these steps, just to have the same result.
# Oriol _ (8 years ago)
Not only size
. All get
, set
, has
, etc. algorithms in the spec are O(n).
But as explained in www.ecma-international.org/ecma-262/7.0/index.html#sec-map-objects,
# Isiah Meadows (8 years ago)
The only part that matters is that it's observably equivalent
functionally. In theory, indexOf
could be done in constant steps
provided there are no indexed getters or setters, and there's no
overriding proxy hook. It'd be impractical to ensure that, but it's
still theoretically possible to both do that and remaining conformant.
Isiah Meadows me at isiahmeadows.com
In reading the relevant section for the
size
accessors (http://www.ecma- international.org/ecma-262/7.0/index.html#sec-get-map.prototype.size), I'm confused and wondering why this was defined as an O(n) operation in theget
accessor rather than as an additional step in theset
,delete
, andclear
methods to track an internal[[Size]]
variable or something, making the publicsize
accessor capable of being O(1).It seems surprising to me that in order to be spec compliant, Map and Set implementations must implement accessors that have surprising perf implications.