[#98098] [Ruby master Feature#16824] Follow RubyGems naming conventions for the stdlib — shannonskipper@...

Issue #16824 has been reported by shan (Shannon Skipper).

14 messages 2020/05/01

[#98147] [Ruby master Feature#16832] Use #name rather than #inspect to build "uninitialized constant" error messages — jean.boussier@...

Issue #16832 has been reported by byroot (Jean Boussier).

20 messages 2020/05/06

[#98174] [Ruby master Bug#16837] Can we make Ruby 3.0 as fast as Ruby 2.7 with the new assertions? — takashikkbn@...

Issue #16837 has been reported by k0kubun (Takashi Kokubun).

10 messages 2020/05/07

[#98241] [Ruby master Bug#16845] Building Ruby with old existing system Ruby results in make error with ./tool/file2lastrev.rb — erik@...

Issue #16845 has been reported by ErikSwan (Erik Swan).

7 messages 2020/05/09

[#98256] [Ruby master Feature#16847] Cache instruction sequences by default — jean.boussier@...

Issue #16847 has been reported by byroot (Jean Boussier).

16 messages 2020/05/11

[#98257] [Ruby master Feature#16848] Allow callables in $LOAD_PATH — jean.boussier@...

Issue #16848 has been reported by byroot (Jean Boussier).

27 messages 2020/05/11

[#98318] [Ruby master Bug#16853] calling bla(hash, **kw) with a string-based hash passes the strings into **kw (worked < 2.7) — sylvain.joyeux@...4x.org

Issue #16853 has been reported by sylvain.joyeux (Sylvain Joyeux).

12 messages 2020/05/13

[#98355] [Ruby master Bug#16889] TracePoint.enable { ... } also activates the TracePoint for other threads, even outside the block — eregontp@...

Issue #16889 has been reported by Eregon (Benoit Daloze).

16 messages 2020/05/14

[#98363] [Ruby master Feature#16891] Restore Positional Argument to Keyword Conversion — merch-redmine@...

Issue #16891 has been reported by jeremyevans0 (Jeremy Evans).

23 messages 2020/05/14

[#98371] [Ruby master Feature#16894] Integer division for Ruby 3 — andrew@...

Issue #16894 has been reported by ankane (Andrew Kane).

18 messages 2020/05/15

[#98391] [Ruby master Bug#16896] MakeMakefile methods should be private — eregontp@...

Issue #16896 has been reported by Eregon (Benoit Daloze).

10 messages 2020/05/15

[#98396] [Ruby master Feature#16897] Can a Ruby 3.0 compatible general purpose memoizer be written in such a way that it matches Ruby 2 performance? — sam.saffron@...

Issue #16897 has been reported by sam.saffron (Sam Saffron).

25 messages 2020/05/16

[#98453] [Ruby master Bug#16904] rubygems: psych: superclass mismatch for class Mark (TypeError) — jaruga@...

Issue #16904 has been reported by jaruga (Jun Aruga).

18 messages 2020/05/20

[#98486] [Ruby master Bug#16908] Strange behaviour of Hash#shift when used with `default_proc`. — samuel@...

Issue #16908 has been reported by ioquatix (Samuel Williams).

14 messages 2020/05/23

[#98569] [Ruby master Bug#16921] s390x: ramdom test failures for timeout or segmentation fault — jaruga@...

Issue #16921 has been reported by jaruga (Jun Aruga).

9 messages 2020/05/29

[#98599] [Ruby master Bug#16926] Kernel#require does not load a feature twice when $LOAD_PATH has been modified spec fails only on 2.7 — eregontp@...

Issue #16926 has been reported by Eregon (Benoit Daloze).

12 messages 2020/05/31

[ruby-core:98333] [Ruby master Feature#16855] Add a tracepoint for warnings

From: merch-redmine@...
Date: 2020-05-13 19:41:38 UTC
List: ruby-core #98333
Issue #16855 has been updated by jeremyevans0 (Jeremy Evans).


Eregon (Benoit Daloze) wrote in #note-3:
> Maybe another angle for this would be to make the `instance variable @foobar not initialized` shown even with the default `$VERBOSE` being `false` (i.e. `rb_warn` instead of `rb_warning`).
> Then people would likely be a lot more eager to fix it.

This would make optimized code slower.  Explicitly initializing instance variables to `nil` can have a significant negative effect on performance.  If you didn't want to explicitly initialize instance variables to `nil`, you would need to protect all access to them with something like `defined?(@ivar)` or by using an `attr_reader` method (which doesn't warn), both of which would also be slower.

> It can be advantageous for performance to have ivars always initialized when reading them, otherwise there is some kind of polymorphism introduced (i.e., executed when the ivar doesn't exist and executed when the ivar exists).

This is only true if the ivars are accessed directly many times.  It isn't until around 50 accesses before it makes sense from a performance standpoint to explicitly initialize ivars to `nil` if you take into account the time taken to explicitly initialize them.

This is not an insignificant performance issue.  Assuming you have 4 instance variables, if you aren't accessing the instance variables, not explicitly initializing them to `nil` is over 60% faster.  If you are only accessing them once, it's over 50% faster.  Even if you are accessing them 10 times, not initializing them is about 20% faster.

For optimal performance, you should only explicitly initialize instance variables to `nil` for long-lived objects.

Benchmark code:

```ruby
require 'benchmark/ips'

class IV
  eval "def check1; #{"@a || @b || @c || @d ||" * 1} nil end"
  eval "def check10; #{"@a || @b || @c || @d ||" * 10} nil end"
  eval "def check50; #{"@a || @b || @c || @d ||" * 50} nil end"
  eval "def check100; #{"@a || @b || @c || @d ||" * 100} nil end"
end

class DefIV < IV
  def initialize; @a = @b = @c = @d = nil end
end

Benchmark.ips do |x|
 x.report("No initialization - No Check"){IV.new}
 x.report("No initialization - Check 1 time"){IV.new.check1}
 x.report("No initialization - Check 10 times"){IV.new.check10}
 x.report("No initialization - Check 50 times"){IV.new.check50}
 x.report("No initialization - Check 100 times"){IV.new.check100}
 x.report("Initialization - No Check"){DefIV.new}
 x.report("Initialization - Check 1 time"){DefIV.new.check1}
 x.report("Initialization - Check 10 times"){DefIV.new.check10}
 x.report("Initialization - Check 50 times"){DefIV.new.check50}
 x.report("Initialization - Check 100 times"){DefIV.new.check100}
end
```

Results with 2.7.1:

```
Calculating -------------------------------------
No initialization - No Check
                          2.255M (_ 0.3%) i/s -     11.295M in   5.007986s
No initialization - Check 1 time
                          1.813M (_ 0.6%) i/s -      9.229M in   5.090357s
No initialization - Check 10 times
                        847.470k (_ 0.3%) i/s -      4.319M in   5.096086s
No initialization - Check 50 times
                        253.392k (_ 0.5%) i/s -      1.291M in   5.094078s
No initialization - Check 100 times
                        135.259k (_ 0.3%) i/s -    689.724k in   5.099341s
Initialization - No Check
                          1.367M (_ 0.3%) i/s -      6.965M in   5.096278s
Initialization - Check 1 time
                          1.203M (_ 0.5%) i/s -      6.134M in   5.097248s
Initialization - Check 10 times
                        711.272k (_ 0.4%) i/s -      3.626M in   5.097540s
Initialization - Check 50 times
                        254.220k (_ 0.3%) i/s -      1.273M in   5.007728s
Initialization - Check 100 times
                        140.121k (_ 0.6%) i/s -    703.400k in   5.020148s
```

----------------------------------------
Feature #16855: Add a tracepoint for warnings
https://bugs.ruby-lang.org/issues/16855#change-85600

* Author: tenderlovemaking (Aaron Patterson)
* Status: Rejected
* Priority: Normal
----------------------------------------
I would like to add a tracepoint for warnings.  I want to do this so that DidYouMean can suggest fixes for instance variables.  I noticed did you mean [has experimental support](https://github.com/ruby/did_you_mean/blob/master/lib/did_you_mean/experimental/ivar_name_correction.rb), but it looks very complicated.  I think if we added a tracepoint for such warnings, DidYouMean can provide more helpful warnings.

I made a pull request [here](https://github.com/ruby/ruby/pull/3106)



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread