The rewritten test is not super clean with the manual cleanup etc.. If this is a
one-off it's not a big deal. However, if in subsequent rewrites I spot more
occurrences of this pattern, then I'll refactor.
Reverts a change from
2327ebfdc6
which can overwrite `test_order` that may have been manually set in
config. This can cause a situation where the user is depending on a
particular `test_order` but is unknowingly forced into another.
`case format when nil` is very efficient because it end up calling `NilClass === nil`
which pretty much translates to `nil.is_a?(NilClass)`.
On the other hand `format.nil?` benefit from a dedicated op code, so it's quite faster.
In this case `Integer#to_s` is much more often called without any arguments,
so it's worth optimizing for the most common case.
```ruby
class Integer
alias_method :faster_to_s, :to_s
end
require 'active_support/all'
require 'benchmark/ips'
module FasterNumericWithFormat
def faster_to_s(format = nil, options = nil)
if format.nil?
return super()
end
case format
when Integer, String
super(format)
when :phone
ActiveSupport::NumberHelper.number_to_phone(self, options || {})
when :currency
ActiveSupport::NumberHelper.number_to_currency(self, options || {})
when :percentage
ActiveSupport::NumberHelper.number_to_percentage(self, options || {})
when :delimited
ActiveSupport::NumberHelper.number_to_delimited(self, options || {})
when :rounded
ActiveSupport::NumberHelper.number_to_rounded(self, options || {})
when :human
ActiveSupport::NumberHelper.number_to_human(self, options || {})
when :human_size
ActiveSupport::NumberHelper.number_to_human_size(self, options || {})
when Symbol
super()
else
super(format)
end
end
end
Integer.prepend(FasterNumericWithFormat)
Benchmark.ips do |x|
x.report('orig no-arg') { 42.to_s }
x.report('fast no-arg') { 42.faster_to_s }
x.compare!
end
Benchmark.ips do |x|
x.report('orig :human') { 42.to_s(:human) }
x.report('fast :human') { 42.faster_to_s(:human) }
x.compare!
end
```
Ruby 2.7.2
```
Warming up --------------------------------------
orig no-arg 567.569k i/100ms
fast no-arg 692.636k i/100ms
Calculating -------------------------------------
orig no-arg 5.709M (± 1.3%) i/s - 28.946M in 5.070660s
fast no-arg 6.892M (± 0.7%) i/s - 34.632M in 5.024961s
Comparison:
fast no-arg: 6892287.7 i/s
orig no-arg: 5709450.0 i/s - 1.21x (± 0.00) slower
Warming up --------------------------------------
orig :human 575.000 i/100ms
fast :human 619.000 i/100ms
Calculating -------------------------------------
orig :human 6.176k (± 1.6%) i/s - 31.050k in 5.028656s
fast :human 6.179k (± 1.8%) i/s - 30.950k in 5.010372s
Comparison:
fast :human: 6179.1 i/s
orig :human: 6176.3 i/s - same-ish: difference falls within error
```
LogSubscriber overrides start/finish to avoid instrumenting when its
logger is nil. In order to support buffered notification events, as used
by async queries, we need to apply a similar override to
LogSubscriber#publish_event.
Date._iso8601 will return a hash for some values eg. '12936' but this will not contain the expected :mon and :mday keys.
Check for these keys and raise an ArgumentError if they aren't present as this is consistent with other invalid input behaviour.
OrderedHash is deprecated but there are some requires and references
to OrderedHash, which might be confusing.
As described in
https://github.com/rails/rails/issues/22681#issuecomment-166059717
OrderedHash is internal only so references in the docs should be
removed.
When requiring only "active_support/hash_with_indifferent_access",
calling `slice!` method on `HashWithIndifferentAccess` object
causes `NoMethodError`.
This is caused by `slice!` method calls `super` which is defined
in "active_support/core_ext/hash/slice" that' not required by this file.
Adding `require "active_support/core_ext/hash/slice"` to hwia
resolves this issue.
Note: since all tests `require_relative "abstract_unit"` that requires
"active_support/core_ext/hash/slice" eventually, it's pretty hard to
test method behavior without require.
Setting up the parallel workers could be an overhead when running
individual files.
This patch disables that process in case the number of files to run
is less than one.
Results running a sample file:
Before:
```
actionpack $ bin/test test/controller/parameters/accessors_test.rb
Run options: --seed 48261
........................................................................
Finished in 0.211923s, 339.7460 runs/s, 552.0873 assertions/s.
72 runs, 117 assertions, 0 failures, 0 errors, 0 skips
```
After
```
actionpack $ bin/test test/controller/parameters/accessors_test.rb
Run options: --seed 5461
........................................................................
Finished in 0.008411s, 8560.2189 runs/s, 13910.3557 assertions/s.
72 runs, 117 assertions, 0 failures, 0 errors, 0 skips
```
This starts a series of patches in which we drop classic mode. The final
result no longer has a const_missing callback, there is no hook/unhook,
and so on.
So, in this patch we remove the ability of configuring classic, but some
of the code that remains will be further refactored.
It is not uncommon for `sql.active_record` subscribers to rely on
thread local or fiber local state. For instance the `buffered-logger`
gem buffer the logs in a thread variable.
With the introduction of async queries, the `sql.active_record`
events can now be produced from a background thread and that break
some expectations.
This makes it hard for subscriber to map the event to the request
or job that scheduled it.
That is why I believe we should instead store the event and
publish it back on the calling thread when the results are
accessed.
I'm writing this patch for two purposes:
1. I want to reduce the number of times `object_id` is called. Calling
`object_id` can have negative impacts on performance in Ruby 2.7+, so
it would be nice to stop calling it.
2. I'm not sure why we're treating lambdas specially here. It looks
like we wanted to prevent people from skipping callbacks that were
defined with a lambda, but I think that is silly. If the user has a
reference to a lambda, and they want to skip it, we should let them.
I think this cleans up some code, helps with performance, and is a more
intuitive interface.
Currently if you do `config.cache_store = :file_store` in an initializer, your app will boot and the cache contents will be stored in a directory called `{}` in your project root. This is unlikely to be the intended outcome.
This PR raises an error if you call `config.cache_store = :file_store` without a path. The correct way to use the default cache path is `config.cache_store = :file_store, "#{config.root}/tmp/cache/"`.
To preserve the current behavior:
```ruby
config.cache_store = :file_store, "{}"
```
Co-authored-by: Ryuta Kamizono <kamipo@gmail.com>
RDoc Markup does not support backticks the way Markdown does to mark up
inline code. Additionally, `<tt>` must be used to mark up inline code
that includes spaces or certain punctuation characters (e.g. quotes).
Follow-up to #41404.
These tests will prevent regressions if we decide to change the
implementations of `maximum` or `minimum` in the future (for example,
calling `max_by` or `min_by` followed by `send`).
Users of `:dalli_store` may have been passing an explicit `nil` parameter for the servers:
```ruby
config.cache_store = :dalli_cache, nil, { expires_in: 2.hour, compress: true }
```
If they simply changed `:dalli_cache` and `:mem_cache_store`, the existing code passes `addresses = [nil]` to Dalli (instead of `nil`), which cause exceptions when people try to access the cache:
```
> Rails.cache.fetch('foo')
NoMethodError: undefined method `match' for nil:NilClass
```
This change allows users to continue passing the explicit `nil`, making migrations from `:dalli_store` to `:mem_cache_store` simpler.
Xavier Noria