From: Sylvain Joyeux Date: 2016-09-13T13:57:31-03:00 Subject: [ruby-core:77262] RFC: optimizations opportunities in Hash#merge! --===============2038035248== Content-Type: multipart/alternative; boundary=001a1142bed228e0f2053c66821e --001a1142bed228e0f2053c66821e Content-Type: text/plain; charset=UTF-8 Hello everyone. I'm using Hash#merge and other hash-related update methods extensively, to the point where I spend a significant amount of time in #hash. So I went digging. It appears that Hash#merge is actually re-hashing its keys twice (once to compare the two hashes, and once to re-assign to the receiver). However, under the assumption that the block in Hash#merge! is not allowed to modify the key, no hashing should be needed at all. Or am I missing something ? I am ready to work on this, but I want to have a feel for whether such work would be welcome by the code devs before I invest time in it ... rather than have it thrown away as WONTFIX later. Regards, Sylvain --001a1142bed228e0f2053c66821e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone.

I'm using Hash#merg= e and other hash-related update methods extensively, to the point where I s= pend a significant amount of time in #hash.

So I w= ent digging. It appears that Hash#merge is actually re-hashing its keys twi= ce (once to compare the two hashes, and once to re-assign to the receiver).=

However, under the assumption that the block in H= ash#merge! is not allowed to modify the key, no hashing should be needed at= all.

Or am I missing something ?

I am ready to work on this, but I want to have a feel for whether = such work would be welcome by the code devs before I invest time in it ... = rather than have it thrown away as WONTFIX later.

= Regards,
Sylvain
--001a1142bed228e0f2053c66821e-- --===============2038035248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Unsubscribe: --===============2038035248==--