You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not saying we should do this but we if we accept the extra cost of a field or get clever we can cache the hashValue of a frozen string and literal string lookups can be at same speed as symbols. when unfrozen we need to invalidate that hashValue safely.
There are two sides to this as well. In a non-de-duped non-literal string key (but frozen from being a key we do not need to recalc hash value over and over for the key when traversing a hash bucket. From the client side people who explicitly freeze their strings will get near de-duped performance since object identity will fail but test-key and keys will be cached hash compares.
The text was updated successfully, but these errors were encountered:
I am not saying we should do this but we if we accept the extra cost of a field or get clever we can cache the hashValue of a frozen string and literal string lookups can be at same speed as symbols. when unfrozen we need to invalidate that hashValue safely.
There are two sides to this as well. In a non-de-duped non-literal string key (but frozen from being a key we do not need to recalc hash value over and over for the key when traversing a hash bucket. From the client side people who explicitly freeze their strings will get near de-duped performance since object identity will fail but test-key and keys will be cached hash compares.
The text was updated successfully, but these errors were encountered: