[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
ko1@atdot.net wrote:
Eric Wong <normalperson@yhbt.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
On 2014/10/09 11:04, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
On 2014/10/09 20:41, Xavier Noria wrote:
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, normal@ruby-lang.org wrote:
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
2014-10-16 12:48 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
[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.