From: "Marcin Mielżyński" Date: 2008-04-02T00:50:09+09:00 Subject: Re: Why Ruby do not optimize code at all? ts wrote: > Marcin Mielżyński wrote: >> Not true. The instruction itself is responsible for the fallback (just >> not implemented yet). > > vgs% ./ruby -ve 'case "a"; when :a; p :ok; end' > ruby 1.9.0 (2008-04-01 revision 15881) [i686-linux] > vgs% Actually, same happens for 1.8.6 (more Symbol#=== issue), but I'm aware of your point. > > It's a bug : it's useless to add an optimisation which *break* > some code and in this case the fallback is *precisely* to call > Symbol#===, i.e. to bypass the optimisation. Well, that's why I'd rather call it temporary breakage since the sources say the author's been aware of it from very beginning (chance the TODO: comment). Just, opt_case_dispatch impl is not complete _yet_, still being faster by default by not using funcall dispatch. Actually a bug (but different) I'd call a compiler issue generating opt_case_dispatch even with specialized_instruction option turned off, so: opts = VM::InstructionSequence.compile_option opts[:specialized_instruction] = false VM::InstructionSequence.compile_option = opts s = VM::InstructionSequence.new %{ class Symbol def === other puts "foo" end end case :s when :s end } s.eval s.disam: 0000 putnil ( 2) 0001 putnil 0002 defineclass :Symbol, , 0 0006 pop 0007 putobject :s ( 7) 0009 dup 0010 opt_case_dispatch , 25 0013 putobject :s ( 8) 0015 topn 1 0017 send :===, 1, nil, 0, 0023 branchif 29 0025 pop ( 7) 0026 putnil 0027 leave 0028 pop 0029 pop ( 9) 0030 putnil 0031 leave ( 8) == disasm: @>============================= 0000 putnil ( 3) 0001 definemethod :===, ===, 0 0005 putnil 0006 leave == disasm: >======================================== local table (size: 2, argc: 1 [opts: 0, rest: -1, post: 0, block: -1] s1) [ 2] other 0000 putnil ( 4) 0001 putstring "foo" 0003 send :puts, 1, nil, 8, 0009 leave lopex