From: "sam.saffron (Sam Saffron)" <sam.saffron@...>
Date: 2013-12-23T16:11:54+09:00
Subject: [ruby-core:59277] [ruby-trunk - Bug #9262] global_method_cache	should be configurable or grow automatically


Issue #9262 has been updated by sam.saffron (Sam Saffron).


There was a concern that gettimeofday is expensive and adds too much time to my results

I measured: 

static VALUE
rb_timing_overhead_per_100k(VALUE klass){
    int i, iterations = 100000;
    struct timeval temp,tv1,tv2,res;

    gettimeofday(&tv1, NULL);
    for(i=0; i<iterations; i++) {
	gettimeofday(&temp, NULL);
    }
    gettimeofday(&tv2, NULL);

    timersub(&tv2, &tv1, &res);
    return INT2FIX(res.tv_sec*100000 + res.tv_usec);
}

turns out that its 2000 microseconds per 100k calls, so the additional time involved due to measuring is negligible, the numbers can be trusted



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

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/