| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This commit undoes 54243fe.
Reason: Further investigation has shown the benefit is not so clear
generally speaking.
There is a long discussion and several benchmarks in the PR #24658
if you are interested in the details.
|
|
|
|
|
|
| |
This alternative flows better.
[Richard Schneeman & Xavier Noria]
|
|
|
|
|
|
|
|
|
| |
Further investigation seems to disprove that backtracking is the
reason why the positive variant is slower, see
https://github.com/rails/rails/pull/24658#issuecomment-213079710
so, just say nothing about it, only assert it is slower.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you come here without context, it is important to hightlight that
checking the predicate is worthwhile due to the observation that blank
strings are often empty. So you complicate the code (which has a cost
in terms of readability and aesthetics), but statistically makes sense.
Then, you also need to explain why the second operand is so convoluted.
Otherwise, you wonder why this line is written precisely this way. That
is what code comments are for.
|
|
|
|
| |
Follow up to #24658.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow up on https://github.com/rails/rails/commit/697384df36a939e565b7c08725017d49dc83fe40#commitcomment-17184696.
The regex to detect a blank string `/\A[[:space:]]*\z/` will loop through every character in the string to ensure that all of them are a `:space:` type. We can invert this logic and instead look for any non-`:space:` characters. When that happens, we would return on the first character found and the regex engine does not need to keep looking.
Thanks @nellshamrell for the regex talk at LSRC.
By defining a "blank" string as any string that does not have a non-whitespace character (yes, double negative) we can get a substantial speed bump.
Also an inline regex is (barely) faster than a regex in a constant, since it skips the constant lookup. A regex literal is frozen by default.
```ruby
require 'benchmark/ips'
def string_generate
str = " abcdefghijklmnopqrstuvwxyz\t".freeze
str[rand(0..(str.length - 1))] * rand(0..23)
end
strings = 100.times.map { string_generate }
ALL_WHITESPACE_STAR = /\A[[:space:]]*\z/
Benchmark.ips do |x|
x.report('current regex ') { strings.each {|str| str.empty? || ALL_WHITESPACE_STAR === str } }
x.report('+ instead of * ') { strings.each {|str| str.empty? || /\A[[:space:]]+\z/ === str } }
x.report('not a non-whitespace char') { strings.each {|str| str.empty? || !(/[[:^space:]]/ === str) } }
x.compare!
end
# Warming up --------------------------------------
# current regex
# 1.744k i/100ms
# not a non-whitespace char
# 2.264k i/100ms
# Calculating -------------------------------------
# current regex
# 18.078k (± 8.9%) i/s - 90.688k
# not a non-whitespace char
# 23.580k (± 7.1%) i/s - 117.728k
# Comparison:
# not a non-whitespace char: 23580.3 i/s
# current regex : 18078.2 i/s - 1.30x slower
```
This makes the method roughly 30% faster `(23.580 - 18.078)/18.078 * 100`.
cc/ @fxn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See the rationale in the comment in this patch.
To benchmark this I ran a number of variations, ultimately narrowing to
require 'benchmark/ips'
str = ''
regexp = /\A[[:space:]]*\z/
Benchmark.ips do |x|
x.report('regexp') { regexp === str }
x.report('empty') { str.empty? || regexp === str }
x.compare!
end
This benchmark has consistently reported speedups around 3.5x:
Calculating -------------------------------------
regexp 69.197k i/100ms
empty 115.468k i/100ms
-------------------------------------------------
regexp 2. 6.3%) i/s - 13.839M
empty 9. 8.8%) i/s - 47.804M
Comparison:
empty: 9642607.6 i/s
regexp: 2768351.9 i/s - 3.48x slower
Sometimes even reaching 4x.
Running the same bechmark on strings of 10 or 100 characters (with
whitespace or present) has shown a slowdown of just about 1.01/1.02.
Marginal, we seem to have a worthwhile trade-off here.
|
|
|
|
|
|
|
| |
The concept of a blank date or time doesn't make sense so we can short
circuit the calls for `blank?` on these classes to gain small speed boost.
Fixes #21657
|
| |
|
| |
|
|
|
|
| |
just needed some tenderloving instance_eval to fit the bill
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The contract of blank? and present? was in principle to return Object, as we
generally do, the test suite and description was consistent with that, but some
examples had comments like "# => true".
This cannot be unclear, we either fix the examples, or update the contract.
Since users may be already assuming singletons due to the examples and the fact
that they were returned before 30ba7ee, the safest option seems to be to revise
the contract and the implementation of String#blank?
The motivation for 30ba7ee was to improve the performance of the predicate, the
refactor based on === is on par regarding speed.
With this commit we start documenting return types using YARD conventions. We
plan to document return types gradually.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Object class. An Object doesn't need to be nil and empty to be blank? just one or the other."
Reason: the original code is correct, see
!nil && !empty -> !(nil || empty) -> !blank
That said, this example has too many negations
for my linking. Think should be revised to be
more positive and straightforward to read.
This reverts commit a4b6e3d9be338e93320606f7cb14759b26ced8df.
|
|
|
|
| |
class. An Object doesn't need to be nil and empty to be blank? just one or the other.
|
| |
|
|
|
|
|
|
|
| |
Reason: "To be blank" and "to be empty" belongs to our everyday
terminology, they go in regular font.
This reverts commit 280a8709923d2bf707ec4d82ac1e5cb14941da3d.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
's/[ \t]*$//' -i {} \;)
|
|
|
|
| |
returns nil [DHH/Colin Kelley]
|
|
|