Adopt three more open benchmark PRs - #246
Merged
Merged
Conversation
From #139 by @lvl0nax, which added String#include? to the Regexp benchmark, ===-vs-=~-vs-match.rb. include? does not match a Regexp, it looks for a fixed substring, so it gets its own file, include-vs-match.rb, against the Regexp ways to find the same substring. The PR found include? about 2x faster than =~ on Ruby 2.4.2, and it still beats =~ everywhere. String#match?, added in Ruby 2.4, is as fast or faster on current CRuby, so it is named the winner: faster match?, fast include?, slow =~. On Ruby 3.4 match? is 1.39x ahead of include?, on 4.0 1.17x; include? wins on 2.1, which has no match? (that report is guarded), and on JRuby. README: - The ===-vs-=~-vs-match entry gets back its Ruby 2.2.2 sample from the git history, and keeps #139's Ruby 2.4.2 run (the Regexp file plus include?) with a note, before the 4.0.0 sample main had. - A new entry for include-vs-match.rb, with runs on Ruby 3.4 and 4.0.7. Co-authored-by: Dmitrii Gautsel <1892604+lvl0nax@users.noreply.github.com>
…op vs while true (#228, #143) From #143 by @styd (begin...end until) and #228 by @ydakuka (until false and an endless range), which both extend loop-vs-while-true.rb, so they land together as five reports. Changes to the PRs: - Kept the file name loop-vs-while-true.rb instead of #228's new one, so its results keep their history, and the existing labels. - Rank names: fastest begin...end until (first on Ruby 2.1 and 3.4), faster while true, fast until false, slow loop, slower endless range. The three loops that test a condition tie on Ruby 4.0; a comment says so. - (0..) is Ruby 2.6+ syntax, which older Rubies cannot even parse, so that method is defined from a string with eval and its report only runs on 2.6+. (0..Float::INFINITY) would parse, but it is 2x to 2.6x slower than (0..), so it would not measure the same thing. - Dropped the editor swap file .README.md.swp that #143 committed. The README entry names all five and keeps every run: 2.2.3 from the git history, 2.5.0 from #143, 3.3.0dev from #228, new 3.4 and 4.0.7 runs, and 4.0.0 as on main. Co-authored-by: Adrian Setyadi <8341867+styd@users.noreply.github.com> Co-authored-by: Yauheni Dakuka <10832262+ydakuka@users.noreply.github.com>
JuanVqz
marked this pull request as ready for review
September 29, 2026 18:03
This was referenced Sep 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Changes
Step 1:
String#match?vsString#include?vsString#=~for a fixed substring (#139 by @lvl0nax)String#include?to the Regexp benchmark,===-vs-=~-vs-match.rb.include?looks for a fixed substring, it does not match a Regexp, so it gets its own file,string/include-vs-match.rb, against the Regexp ways to find the same substring.include?about 2x faster than=~on Ruby 2.4.2, and it still beats=~everywhere.String#match?, added in Ruby 2.4, is as fast or faster on current CRuby (1.39x ahead ofinclude?on 3.4, 1.17x on 4.0), so it is named the winner. Its report only runs on Ruby 2.4+.===entry in the README gets back its Ruby 2.2.2 sample from the git history, and keeps add substring inclusion checking #139's Ruby 2.4.2 run with a note. The new entry has runs on Ruby 3.4 and 4.0.7.Step 2:
begin...end until,until falseand an endless range inloopvswhile true(#143 by @styd, #228 by @ydakuka)loop-vs-while-true.rb, whose name and labels stay, so its results keep their history:begin...end until(first on Ruby 2.1 and 3.4),while true,until false,loop, and the endless range. The three loops that test a condition tie on Ruby 4.0.(0..)is Ruby 2.6+ syntax, which older Rubies cannot parse, so that method is defined from a string withevaland its report only runs on 2.6+.(0..Float::INFINITY)would parse, but it measured 2x to 2.6x slower than(0..)..README.md.swpthat Add 'Begin Until' to the loop battle #143 committed.main.Test plan
include-vs-match.rbruns on Ruby 2.1 and JRuby 9.1.loop-vs-while-true.rbruns four reports on 2.1, 2.5 and JRuby 9.1, and all five on 2.6 and TruffleRuby 22.include-vs-match.rbon 2.1, 2.5, 3.4, 4.0, JRuby head and TruffleRuby head;loop-vs-while-true.rbon 3.4 and 4.0 (and an earlier version, with(0..Float::INFINITY), on 2.1).After this merges, #139, #143 and #228 each get a comment saying where they landed, and are closed.