vmakarov / redhat.com wrote:
> I think I'll have a few patches when I am done with the hash
> tables: the hash table itself, hash functions, code for
> recognizing a denial attack and switching to stronger hash
> functions.  I am not sure that all (or any) will be finally
> accepted.

I look forward to these and would also like to introduce some
new APIs for performance.

One feature would be the ability to expose and reuse calculated
hash values between different tables to reduce hash function
overheads.

This can be useful in fstring and symbol tables where the same
strings are repeatedly reused as hash keys.

For example, I was disappointed we needed to revert r43870 (git
commit 0c3b3e9237e8) in [Misc #9188] which deduplicated all
string keys for Hash#[]=:

	https://bugs.ruby-lang.org/issues/9188

So, perhaps being able to reuse hash values between different
tables can improve performance to the point where we can dedupe
all string hash keys to save memory.

I am also holding off on committing a patch to dedupe keys
from Marshal.load [Feature #12017] because I hope to resurrect
r43870 before Ruby 2.4:

	https://bugs.ruby-lang.org/issues/12017

I had another feature in mind, but can't remember it at the
moment :x

I doubt I'll have time to work on any of this until you're done
with your work.  My time for ruby-core is limited for the next
2-3 months due to vacations and other projects.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>