Add option --dont-start and make current profile available as RubyProf::Profile.current

[paddor]

This relates to #329.

Since "paused" means running+paused, I didn't name the new option --start-paused, but --dont-start.

RubyProf::Profile#initialize now sets RubyProf::Profile.current.

Tested successfully with this script:

1000.times { puts "." }
RubyProf::Profile.current.start unless RubyProf::Profile.current.running?
1000.times { print "." }

For some reason the ruby-prof executable had CRLF line endings, which refused to run in my Linux VM. I changed it to LF (Unix). Or did I miss something?

[cfis]

Thanks for working this. A couple things:

• could you update the commit so it doesn't look like every line changed in the ruby-prof script? Makes it hard to review.
• the test_current test fails when running github actions.

[paddor]

Ok, I've reverted back to DOS format and fixed the spec.

[cfis]

Don't mind switching to Unix format, just in a different commit (and all files in repo should have the same line endings of course). Will need to check that.

[cfis]

This create a reference from an instance of a profile to itself in Ruby. So let's not do that because it can only do bad things to the GC.

Instead, look at how the running? method is implemented and copy that.

[paddor]

I'm pretty sure sets a class-level instance variable on RubyProf::Profile which points to the instance. Otherwise the test wouldn't work. I want to make the RubyProf::Profile instance available, not the prof_profile_t*.

[cfis]

Right, sorry, I misread cProfile as profile.

However, I don't love this change because it is creating a global variable for a single use case. I can't see any reason why someone would create two different profiles at the same time, but it should work correctly, and this change would break it.

Having said that, I can live with the more limited change of the ruby-prof script setting it because that's a more limited change.

[paddor]

We could just set it on RubyProf::Cmd instead.

[paddor]

Now it works exactly the way I originally planned. I had to add the kwarg paused: to #start and #profile.

Verifiable with this test script:

def foo = +"foo"
def bar = +"bar"

10_000.times { foo }
RubyProf::Profile.current.resume
10_000.times { bar }

[cfis]

Seems weird to call profile.start(paused: true) - because then start is not actually starting the profile at all.

An alternative would be Profile.new(paused: true) but not sure I like that any better.

Thinking out loud, in your use case, you are using ruby-prof script, but you still have to add in code like this:

if defined?(RubyProf)
  RubyProf::Profile.current.resume
end

Ruby prof of course knows every method that is called, so would something like this be better inside ruby-prof script?

profile = Profile.new
profile.start_at('MyClass::my_mthod')

So tell RubyProf to start profiling once a particular method is triggered?

[paddor]

Yeah the start_at sounds pretty good too. Actually even better, since the profiled script/app doesn't need to know anything about RubyProf.

[cfis]

You could actually prototype this in Ruby fairly quickly.

Add Profile#start_method, take one parameter start_method (ie, "SomeClass#some_method"). Then use tracepoints (https://docs.ruby-lang.org/en/master/TracePoint.html) to listen for RUBY_EVENT_CALL and RUBY_EVENT_C_CALL. If the method matches start_method, then stop the tracepoint and then call profile.start.

If that works ok, it would be fairly easy to translate to c.