what's the profit from using binary tree in place of hash? 20.03.2014 11:12 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Eric Wong" <normalpe= rson / yhbt.net> =CE=C1=D0=C9=D3=C1=CC: > SASADA Koichi <ko1 / atdot.net> wrote: > > (2014/03/18 8:03), Eric Wong wrote: > > > Global method cache is power-of-two-sized; so it should have a good > hash > > > function. In vm_method.c: > > > > FYI (maybe you know): funny_fulcon proposed to replace global cache by > > per-class cache. > > https://bugs.ruby-lang.org/issues/9262 > > Yes, that issue is for growing global cache, though. It seems per-class > cache idea is dead for now. > > Long term hope is to get rid of the global cache and only use inline > cache. > > ihash[1] with hash-based IDs[2] should be faster than the current st.c + > incrementing IDs. However my primary goal of ihash was memory saving, > but speed should happen because of reduced indirection. > > I will also try RB tree (steal rb.h from jemalloc) or splay tree > (*BSD sys/tree.h) for method tables/constants. id/symbol table > might be too big for a binary search tree. > > > [1] - https://bugs.ruby-lang.org/issues/9614 > git://80x24.org/ruby.git ihash5 > > [2] - not implemented, yet, probably not going to touch parse.y > until Symbol GC patch is merged. >