From: Eric Wong <normalperson@...>
Date: 2014-11-11T08:49:27+00:00
Subject: [ruby-core:66199] Re: [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations

ko1@atdot.net wrote:
> Eric Wong wrote:
> >  > My comments:
> >  > 
> >  > 1. (negative) Incompatibility
> >  
> >  > To solve this incompatibility, I have several ideas.
> >  > 
> >  > (1-1) Make new instruction to replace with receiver.
> >  
> >  I added a new opt_str_lit_yoda instruction.  It only handles one receiver
> >  location for now, I'm not sure if other cases (e.g. gsub) can trigger
> >  the incompatibility.
> >  
> >  patch: http://80x24.org/spew/m/38d41def78f16bca14fbc7fccd160ef0a8d06479.txt
> >  
> >  Right now, I do not optimize `str.gsub("bar", method_call)', yet,
> >  only optimizing: `str.gsub(anything, "bar")'
> >  
> >  	"foo" == bar
> >  
> >  Compiles to:
> >  
> >    [:putobject, "foo"],
> >    [:putself],
> >    [:opt_send_without_block,
> >     {:mid=>:bar, :flag=>280, :orig_argc=>0, :blockptr=>nil}],
> >    [:opt_str_lit_yoda, ["foo", 17, 1]],
> >    [:opt_eq, {:mid=>:==, :flag=>256, :orig_argc=>1, :blockptr=>nil}],
> 
> I raed the implementation of "opt_str_lit_yoda". Is this a not bitmap version (single string) of "opt_stringliteral"?
> You don't use bitmap, because of implementation reason?

Right, it only affected methods with one string literal arg.
It was a little easier to implement without bitmap.

> BTW, why the name "yoda"?

Named after the syntax of the Star Wars character:
https://en.wikipedia.org/wiki/Yoda_Conditions

> >  > (1-3) Ignore such incompatibility because nobody write such code
> >  
> >  However, I hope we can ignore the strange case and new insn.
> 
> Me too.
> (but also I think such restriction is challenging)
> 
> >  > 2. (negative) Live patching
> >  
> >  I've removed live patching for now:
> >    http://80x24.org/spew/m/86739be08df5b4128e84bce15a2853cd7947a6fa.txt
> >  It was a good learning experience, at least.
> 
> Thank you.
> 
> Please do not think that I stick to avoid live patching.
> If we can have huge performance improvement, we need to consider about it.

OK, we can also make a compile-time option.

> >  > Have you measure performance improvement on non-microbenchmarks?
> >  
> >  "make rdoc" performance improved from 66.3 => 63.3 sec in original test
> >  
> >  However, the difference seems is smaller now: 66.1 => 64.9 sec
> 
> What does it means? what is "now"?

I was not able to replicate the original results, probably because other
changes in trunk affected performance.

I'll check other issues tomorrow.

About the discourse benchmark: it seems discourse and libraries already
use .freeze frequently; so the performance may not be noticeable in
application which is already optimized by Ruby experts.

In our stdlib, I hope to make parts of r47073, r47072 unnecessary
and revert the "literal".freeze calls.

For instance, rack.git has commit dc53a8c26dc55d21240233b3d83d36efdef6e924
("Less allocated objects on each request"), which is ugly, but
apparently important for performance.

My goal is to make optimization transparent to non-experts
(and prettier code for all)