Aaron Patterson <tenderlove / ruby-lang.org> wrote:
> On Thu, Dec 03, 2015 at 10:51:08PM +0000, Eric Wong wrote:
> > Perhaps you can simplify the code so the existing monomorphic cache is
> > just: POLYMORPHIC_CACHE_SIZE == 1
> 
> Yes, I'd love to do that.  The reason I didn't is because it looks like
> there are a bunch of other places that allocate an rb_call_cache
> directly and directly set the cached members.
> 
> I wanted to keep this patch as small as possible to a) figure out if we
> want to do it (check benchmarks etc), and b) try to figure out what the
> actual size should be.

Benchmarks will likely vary with the old cache in the way,
especially when accessing some fields requires pulling in extra
CPU cache lines.

> No, I haven't measured startup performance.  I've run tests suites from
> a few different projects and didn't notice any startup difference, but I
> didn't test the time specifically.  Do you have any suggestions for how
> to best do that?

I was recently annoyed at how long 'sequel' was taking a while to load
in scripts I was running.  Even "sequel --version" takes 143ms on my
system.  It went up to 146ms with your patch, so there's a tiny
regression there, but no deal breaker.

There's bigger wins to be gained in startup performance (AOT
compilation), using fstatat where available to reduce string
lengths and reduce in-kernel path resolution overhead, etc...