On Fri, Dec 04, 2015 at 02:28:57AM +0000, Eric Wong wrote:
> 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...

Probably OT for this list, but do you have sequel installed as a gem?
If so, can you try running against rubygems master?  I've put some
patches on RubyGems master that *should* speed up loading gems.  Maybe
it will help.  :)

-- 
Aaron Patterson
http://tenderlovemaking.com/