From: normalperson@... Date: 2014-01-29T19:30:41+00:00 Subject: [ruby-core:60227] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically Issue #9262 has been updated by Eric Wong. Eric Wong wrote: > 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 should add: a cheap way to do this might be to just use a do/while macro wrapping rb_funcall with a static __thread rb_call_info_t variable in its scope. __thread works on gcc and clang, and maybe other compilers, too, but other compilers may be stuck with the slow version (or non-MT-safe). (I prefer we use __thread in case we get rid of GVL) ---------------------------------------- Bug #9262: global_method_cache should be configurable or grow automatically https://bugs.ruby-lang.org/issues/9262#change-44706 * Author: Aman Gupta * Status: Open * Priority: Normal * Assignee: Koichi Sasada * Category: * Target version: next minor * ruby -v: trunk * 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/