Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Q&D driver method #133

Open
zenspider opened this issue Jan 5, 2024 · 4 comments · May be fixed by #134
Open

Add Q&D driver method #133

zenspider opened this issue Jan 5, 2024 · 4 comments · May be fixed by #134

Comments

@zenspider
Copy link
Contributor

I have to look up Benchmark.ips EVERY time and the (ri) doco is still a PITA.

Pls consider a simple top level driver method like so:

def quick_bench_ips(*methods, warm:nil, time:nil, show:nil)
  Benchmark.ips do |x|
    x.warmup = warm if warm
    x.time   = time if time
    x.compare!

    if show then
      max = methods.map(&:size).max
      methods.each do |name|
        val = send name
        puts "%*s: %p" % [max, name, val]
      end
      return
    end

    methods.each do |name|
      x.report(name) do |x|
        x.times { send name }
      end
    end
  end
end



def report_tally1
  # ...
end

def report_tally2
  # ...
end

def report_tally3
  # ...
end

quick_bench_ips(:report_tally1,
                :report_tally2,
                :report_tally3)
@zenspider
Copy link
Contributor Author

Ever since I scratched this up I've been driving all my benchmarks via this w/ zero arg methods for clean comparisons. It's helped clean up a lot.

@eregon
Copy link
Contributor

eregon commented Jan 5, 2024

send is quite a big overhead, so that should be addressed (e.g. via eval) if such a convenience method is added.

@zenspider
Copy link
Contributor Author

one could say the same about block activation.

I don't care how it is implement as long as it is easy to use... but as long as it is uniform over all the benchmarks it should be fine. easy enough to crib up an empty method to see what overhead looks like.

@evanphx
Copy link
Owner

evanphx commented Jan 6, 2024

I think the send overhead is probably fine since the user would likely be measuring the results against previous results generated the same way. For super tight code, it might overwhelm the results but not most of the time.

@zenspider Thoughts about having the method take the x param so it can do the x.times loop? Or do you feel like that's bleeding too many details?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants