From: Eric Wong <normalperson@...>
Date: 2014-10-16T06:27:08+00:00
Subject: [ruby-core:65755] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string

ko1@atdot.net wrote:
> I can't find out which methods are target.
> How to see the list?
> 
> I'm afraid that many optimized methods becomes overhead for non-target methods.

Most comments + optimization are in compile.c (still awork-in-progress).
The peephole optimization phase rewrites many
putstring instructions to opt_str_lit instructions (same insn length).

Sorry my last (v2) patch is dirty.  Still a work-in-progress.
I'll try to get an updated patch out this week.

For sub/gsub/tr* methods, the optimization is an obvious win: the only
common use for methods with those method names is with the String class;
so it is effective.

I think start_with?/end_with?/squeeze/pack/unpack fall into the same
category: common case is only one core class uses them with string
literals.  This makes opt_str_lit a win with those method names.

For some method names (include?/delete/key?); I see them often used with
both core (Array/Hash) and non-core (Set/GDBM) classes.
We need to be careful with common method names and string literal.

Maybe we may use dynamic instruction rewriting if we detect uses on
non-core classes and dynamically rewrite opt_str_lit back to putstring.

Note: opt_str_lit has the same insn length as putstring;
we may rewrite iseq->iseq at runtime.