Issue #10585 has been updated by Yura Sokolov.


khash were not best solution cause it doesn't store hashsum. Did you store string's hashsum as a part of a key?

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

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

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.

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.

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.

----------------------------------------
Feature #10585: struct: speedup struct.attr = v for first 10 attributes and struct[:attr] for big structs
https://bugs.ruby-lang.org/issues/10585#change-50382

* Author: Yura Sokolov
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: current: 2.2.0
----------------------------------------
0001 - Define optimized setters for first 10 attributes.

0002 - Cache members definition in an subclasses - it is safe cause it could be modified/overloaded.
And use `rb_attr_get` to lookup definition - it is safe cause result is checked later and `Qnil` is treated as error.

0003,0004 - Use custom hash structure (on top of Array) to lookup members index in a big structure.
Well, I doubt that big structures are useful, so I will not grieve if 0004 is not accepted.

---Files--------------------------------
0001-struct.c-speedup-struct.name-v-for-small-structs.patch (2.33 KB)
0002-struct.c-cache-member-definition-in-a-subclass.patch (1.09 KB)
0003-benchmark-struct-name.patch (2.42 KB)
0004-struct.c-speedup-for-big-structs.patch (5.47 KB)


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