You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of doing some Profiling, I noticed Primer::Classify::Utilities | infer_selector_key showing up and happened to take a look at its implementation. There's a Hash of about 12 Regexps getting instantiated that don't seem to be needed, and these get matched enough in various usage that even a small speed up might be worth it, if that method gets called thousands of times.
Generally in Ruby, things like String's built-in methods will be faster because they're written in C, unless we need features of Regexp like capture groups. I've got a PR that will fast-follow this Issue getting created, that proposes using Strings in place of Regexp.new.
The text was updated successfully, but these errors were encountered:
mathias
changed the title
Non-idiomatic use of Ruby's Regexp.new where String starts_with? will do
Non-idiomatic use of Ruby's Regexp.new where String start_with? will do
Oct 29, 2024
As part of doing some Profiling, I noticed
Primer::Classify::Utilities | infer_selector_key
showing up and happened to take a look at its implementation. There's a Hash of about 12Regexp
s getting instantiated that don't seem to be needed, and these get matched enough in various usage that even a small speed up might be worth it, if that method gets called thousands of times.Generally in Ruby, things like String's built-in methods will be faster because they're written in C, unless we need features of Regexp like capture groups. I've got a PR that will fast-follow this Issue getting created, that proposes using Strings in place of Regexp.new.
The text was updated successfully, but these errors were encountered: