[ruby-core:60369] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically

Issue #9262 has been updated by Koichi Sasada.

ruby -v changed from trunk to -

 (2014/01/30 4:17), Eric Wong wrote:
 > It looks like the performance regressions w/o global method cache are
 > because rb_funcall and friends do not have call info, so they don't
 > hit the inline cache.  So perhaps we should just add a call info-aware
 > version of rb_funcall-like functions so we can just use inline cache
 > everywhere.
 > 
 > I'm pretty sure ko1 already knows that, but I just discovered it :x
 > tmm1: what do you think?
 > 
 
 charliesome have proposed a simiar API (sorry I forget the URL).
 He use only static variable (not thread-local) and it seems works well.
 However, I think it may have pitfalls (recursive call) so I can't decide
 to introduce it.
 
 
 -- 
 // SASADA Koichi at atdot dot net

----------------------------------------
Bug #9262: global_method_cache should be configurable or grow automatically
https://bugs.ruby-lang.org/issues/9262#change-44849

* Author: Aman Gupta
* Status: Open
* Priority: Normal
* Assignee: Koichi Sasada
* Category: 
* Target version: next minor
* ruby -v: -
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN
----------------------------------------
The global_method_cache is currently a fixed 2048 entries. This is not configurable, and can be inadequate for large applications with thousands of classes and methods.

In our app, increasing the size of the cache to 32768 entries reduced time spent in search_method and overall pressure on st_lookup:

before
      420  14.0% st_lookup
      182   6.1% vm_search_method (inline)

after
      265   9.5% st_lookup
      125   4.5% vm_search_method (inline)

It's possible the VM could grow global_method_cache automatically, using some heuristic based on the number of long-lived classes or method_entries that are defined.
However this would break the hashing in the current implementation.



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