| Age | Commit message (Collapse) | Author |
|
Co-Authored-By: Takashi Kokubun <takashikkbn@gmail.com>
|
|
|
|
This commit adds a specialized instruction for called to `.nil?`. It is
about 27% faster than master in the case where the object is nil or not
nil. In the case where an object implements `nil?`, I think it may be
slightly slower. Here is a benchmark:
```ruby
require "benchmark/ips"
class Niller
def nil?; true; end
end
not_nil = Object.new
xnil = nil
niller = Niller.new
Benchmark.ips do |x|
x.report("nil?") { xnil.nil? }
x.report("not nil") { not_nil.nil? }
x.report("niller") { niller.nil? }
end
```
On Ruby master:
```
[aaron@TC ~/g/ruby (master)]$ ./ruby compil.rb
Warming up --------------------------------------
nil? 429.195k i/100ms
not nil 437.889k i/100ms
niller 437.935k i/100ms
Calculating -------------------------------------
nil? 20.166M (± 8.1%) i/s - 100.002M in 5.002794s
not nil 20.046M (± 7.6%) i/s - 99.839M in 5.020086s
niller 22.467M (± 6.1%) i/s - 112.111M in 5.013817s
[aaron@TC ~/g/ruby (master)]$ ./ruby compil.rb
Warming up --------------------------------------
nil? 449.660k i/100ms
not nil 433.836k i/100ms
niller 443.073k i/100ms
Calculating -------------------------------------
nil? 19.997M (± 8.8%) i/s - 99.375M in 5.020458s
not nil 20.529M (± 7.0%) i/s - 102.385M in 5.020689s
niller 21.796M (± 8.0%) i/s - 108.110M in 5.002300s
[aaron@TC ~/g/ruby (master)]$ ./ruby compil.rb
Warming up --------------------------------------
nil? 402.119k i/100ms
not nil 438.968k i/100ms
niller 398.226k i/100ms
Calculating -------------------------------------
nil? 20.050M (±12.2%) i/s - 98.519M in 5.008817s
not nil 20.614M (± 8.0%) i/s - 102.280M in 5.004531s
niller 22.223M (± 8.8%) i/s - 110.309M in 5.013106s
```
On this branch:
```
[aaron@TC ~/g/ruby (specialized-nilp)]$ ./ruby compil.rb
Warming up --------------------------------------
nil? 468.371k i/100ms
not nil 456.517k i/100ms
niller 454.981k i/100ms
Calculating -------------------------------------
nil? 27.849M (± 7.8%) i/s - 138.169M in 5.001730s
not nil 26.417M (± 8.7%) i/s - 131.020M in 5.011674s
niller 21.561M (± 7.5%) i/s - 107.376M in 5.018113s
[aaron@TC ~/g/ruby (specialized-nilp)]$ ./ruby compil.rb
Warming up --------------------------------------
nil? 477.259k i/100ms
not nil 428.712k i/100ms
niller 446.109k i/100ms
Calculating -------------------------------------
nil? 28.071M (± 7.3%) i/s - 139.837M in 5.016590s
not nil 25.789M (±12.9%) i/s - 126.470M in 5.011144s
niller 20.002M (±12.2%) i/s - 98.144M in 5.001737s
[aaron@TC ~/g/ruby (specialized-nilp)]$ ./ruby compil.rb
Warming up --------------------------------------
nil? 467.676k i/100ms
not nil 445.791k i/100ms
niller 415.024k i/100ms
Calculating -------------------------------------
nil? 26.907M (± 8.0%) i/s - 133.755M in 5.013915s
not nil 25.319M (± 7.9%) i/s - 125.713M in 5.007758s
niller 19.569M (±11.8%) i/s - 96.286M in 5.008533s
```
Co-Authored-By: Ashe Connor <kivikakk@github.com>
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit e352445863588b90f7af6cdf6c1b6dc432ee33ab.
This is breaking CI and I'm not sure why yet, so I'll revert for now.
|
|
|
|
This commit allows the previos EP pointer to move, then updates its
location
|
|
|
|
to suppress a warning
|
|
Because it causes circular require.
|
|
|
|
|
|
Sometimes `Leaked thread: Rinda::TestRingServer#test_ring_server_ipv6_multicast` happens
because `Rinda::TupleSpace#start_keeper` runs after stopping `@keeper`.
|
|
If object was modified, but there is a case that
hash values (#hash) are same between before modified
and after modified objects.
|
|
This recursive iteration test can cause SystemStackError so
check it correctly.
|
|
Surprisingly, on SystemStackError#backtrace can return nil.
|
|
This reverts commit e83ec207cd5fda973c41d6629d8504b515522b12.
|
|
```
warning: Float 0xf.fp10000000000000... out of range
```
|
|
|
|
to suppress the leak checker.
|
|
|
|
|
|
13e84d5c0a changes enum to macro, but the flags usage information
are lost in internal.h. It should be same place with other flags
information.
|
|
|
|
Get rid of "ISO C restricts enumerator values to range of 'int'"
error.
|
|
|
|
On ar_table, Do not keep a full-length hash value (FLHV, 8 bytes)
but keep a 1 byte hint from a FLHV (lowest byte of FLHV).
An ar_table only contains at least 8 entries, so hints consumes
8 bytes at most. We can store hints in RHash::ar_hint.
On 32bit CPU, we use 4 entries ar_table.
The advantages:
* We don't need to keep FLHV so ar_table only consumes
16 bytes (VALUEs of key and value) * 8 entries = 128 bytes.
* We don't need to scan ar_table, but only need to check hints
in many cases. Especially we don't need to access ar_table
if there is no match entries (in many cases).
It will increase memory cache locality.
The disadvantages:
* This technique can increase `#eql?` time because hints can
conflicts (in theory, it conflicts once in 256 times).
It can introduce incompatibility if there is a object x where
x.eql? returns true even if hash values are different.
I believe we don't need to care such irregular case.
* We need to re-calculate FLHV if we need to switch from ar_table
to st_table (e.g. exceeds 8 entries).
It also can introduce incompatibility, on mutating key objects.
I believe we don't need to care such irregular case too.
Add new debug counters to measure the performance:
* artable_hint_hit - hint is matched and eql?#=>true
* artable_hint_miss - hint is not matched but eql?#=>false
* artable_hint_notfound - lookup counts
|
|
iter_lev is used to detect the hash is iterating or not.
Usually, iter_lev should be very small number (1 or 2) so
`int` is overkill.
This patch introduce iter_lev in flags (7 bits, FL13 to FL19)
and if iter_lev exceeds this range, save it in hidden attribute.
We can get 1 word in RHash.
We can't modify frozen objects. Therefore I added new internal API
`rb_ivar_set_internal()` which allows us to set an attribute
even if the target object is frozen
if the name is hidden ivar (the name without `@` prefix).
|
|
|
|
It contains too old configuration that is autorequire. It will be
removed at the RubyGems 3.1.0.
|
|
* `Gem::ConfigMap` is still used by Bundler.
* `Gem::RubyGemsVersion` is also still referred by the old gems.
https://github.com/rubygems/rubygems/commit/249c3ff44f
|
|
https://github.com/rubygems/rubygems/commit/ca8afc01a3
|
|
set it up later and cause confusion
https://github.com/rubygems/rubygems/commit/6ec3ba983c
|
|
not needed anymore
https://github.com/rubygems/rubygems/commit/930de86a24
|
|
extension is used
https://github.com/rubygems/rubygems/commit/2a32c5ef0a
|
|
https://github.com/rubygems/rubygems/commit/107fea3432
|
|
https://github.com/rubygems/rubygems/commit/0402974149
|
|
https://github.com/rubygems/rubygems/commit/be962ca0c4
|
|
https://github.com/rubygems/rubygems/commit/be962ca0c4
|
|
https://github.com/rubygems/rubygems/commit/006cdd4084
|
|
https://github.com/rubygems/rubygems/commit/469fceeb2f
|
|
https://github.com/rubygems/rubygems/commit/1ea674d8f7
|
|
https://github.com/rubygems/rubygems/commit/41b1cebc33
|
|
https://github.com/rubygems/rubygems/commit/70c5c17a5f
|
|
https://github.com/rubygems/rubygems/commit/3d6c7c92e4
|
|
BasicSpecification.
This was never the right place. The method got there just by evolution,
not by design. Move it within default methods, where it suits better.
Since this method is presumably used just internally, it should be safe
to deprecate it and remove later.
https://github.com/rubygems/rubygems/commit/0c0dd9458a
|