From: Eric Wong <normalperson@...>
Date: 2014-12-12T22:01:02+00:00
Subject: [ruby-core:66815] Re: [ruby-trunk - Feature #10585] struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs

funny.falcon@gmail.com wrote:
> khash were not best solution cause it doesn't store hashsum. Did you
> store string's hashsum as a part of a key?

No, I considered doing that but never got around to it.
I worry more about memory usage.

> But i doubt fstring need fast hash. And it needs deletions, so hash
> table could not be simple any way. Or am i mistaken?

khash is fast enough for current uses, I think.  However, I was
sad when r43870 needed to be reverted [misc #9188]

> But if fast hash table will be used for other tables (method table,
> instance variables,for example), that it worth to implement one.

I suspect ordering matters for those, unfortunately [Feature #9614]

> I had done fast symbol table for ruby 1.9.3 and it were not accepted.
> I've done method cache which is used in github ruby build, but not
> accepted in mainline.

Symbol table was largely redone for 2.2 and memory usage decreased a
little.  I still hope we can remove the global method cache someday
(and only use inline cache).

> If one wants to be fast, one need to build specialised structures, and
> it leads to code bloat, so it is not accepted into mainline.

Sometimes.  st performance is good, but it is wasteful.
I've been trying to move to generic stuff, e.g. with ccan/list.
For 2.3, I plan to use ccan/list in st.c [misc #10278] and also
in compile.c (and maybe gc.c).

> If there is real need to improve certain place by fast hash table, i
> will do it with pleasure. But it looks like there is no need.

Fair enough.