From: "tmm1 (Aman Gupta)" Date: 2013-12-23T13:56:25+09:00 Subject: [ruby-core:59275] [ruby-trunk - Bug #9262] global_method_cache should be configurable or grow automatically Issue #9262 has been updated by tmm1 (Aman Gupta). I ran some benchmarks with funny-falcon's patch. Memory usage is increased by 5-10mb RSS in our app, and response time is improved by 4-8%. before: 500 requests to https://github.com/dashboard as tmm1 peak memory: 349.4 MB RSS cpu time: 7,171ms total (14ms avg/req, 13ms - 21ms) 500 requests to https://github.com/github/github/pull/17695 as tmm1 peak memory: 404.6 MB RSS cpu time: 98,713ms total (197ms avg/req, 184ms - 285ms) after: 500 requests to https://github.com/dashboard as tmm1 peak memory: 359.2 MB RSS cpu time: 6,806ms total (13ms avg/req, 12ms - 20ms) 500 requests to https://github.com/github/github/pull/17695 as tmm1 peak memory: 410.3 MB RSS cpu time: 95,559ms total (191ms avg/req, 177ms - 280ms) ---------------------------------------- Bug #9262: global_method_cache should be configurable or grow automatically https://bugs.ruby-lang.org/issues/9262#change-43840 Author: tmm1 (Aman Gupta) Status: Open Priority: Normal Assignee: ko1 (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/