Bug #9703: Inconsistent profile output

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[silverhammermba (Max Anselm)]

The output of the profile lib seems to be partially dependent on how it is required. For example,

ruby -rprofile -e '0==1'

shows one call to Fixnum#== as expected

ruby -e 'require "profile"; 0==1'

does not show any calls to Fixnum#== !!!

ruby -e 'require "profile"; eval("0==1")'

again shows one call to Fixnum#== as expected.

See also: http://stackoverflow.com/questions/22861559/what-is-the-difference-between-r-profile-and-require-profile

[srawlins (Sam Rawlins)]

This is due to profile.rb's :specialized_instruction => false compile option, on line 5. If you comment it out, none of the three cases will show any calls to #==. Specialized instructions are performance-optimized during compile-time. By default, specialized instructions are enabled. In the second example, 0==1 is parsed before require "profile" is evaluated, so that #== is optimized, and not traced. The opposite is true in the first and third examples.

You can also see how 0 == 1 is compiled differently w/ or w/o specialized instructions by comparing:

puts RubyVM::InstructionSequence.compile("0 == 1", "foo.rb", "/foo.rb", 1).disasm

with

puts RubyVM::InstructionSequence.compile("0 == 1", "foo.rb", "/foo.rb", 1, specialized_instruction: false).disasm

If this is not a bug, I think it should be documented, either in Profile, TracePoint, or InstructionSequence. I don't think there is one canonical list of specialized instructions, but a good place to start is iseq_specialized_instruction() and iseq_compile_each()'s case NODE_MATCH.

[naruse (Yui NARUSE)]

• Target version deleted (2.2.0)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed

The profile library was removed in bc76d8a232bed2e245cd3997ebd9826938f7a738.