[#99115] [Ruby master Bug#17023] How to prevent String memory to be relocated in ruby-ffi — larskanis@...
Issue #17023 has been reported by larskanis (Lars Kanis).
22 messages
2020/07/10
[#99375] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings — merch-redmine@...
Issue #17055 has been reported by jeremyevans0 (Jeremy Evans).
29 messages
2020/07/28
[#101207] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings
— merch-redmine@...
2020/12/02
Issue #17055 has been updated by jeremyevans0 (Jeremy Evans).
[#101231] Re: [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings
— Austin Ziegler <halostatue@...>
2020/12/03
What does this mean?
[ruby-core:99395] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings
From:
eregontp@...
Date:
2020-07-29 20:48:06 UTC
List:
ruby-core #99395
Issue #17055 has been updated by Eregon (Benoit Daloze). jeremyevans0 (Jeremy Evans) wrote: > Not initializing instance variables to nil can be much better for performance Why is that? Because just writing extra instance variables in `initialize` is much slower in MRI? It's already an allocation path so it's not that fast anyway (unless escape analyzed, and then writing instance variables should be pretty much free). It seems a very narrow use-case to me, and extremely MRI-specific. In fact I wouldn't be surprised if on other Ruby implementations initializing led to better performance (e.g., no need to grow the ivar storage dynamically later, or change the shape/hidden class). I would much prefer a Warning category for this. Or probably your `warning` gem could be used to suppress those conveniently? Calling more methods when doing warnings is adding more boilerplate, complexity and edge cases to these code paths. ---------------------------------------- Feature #17055: Allow suppressing uninitialized instance variable and method redefined verbose mode warnings https://bugs.ruby-lang.org/issues/17055#change-86836 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- These two verbose mode warnings are both fairly common and have good reasons why you would not want to warn about them in specific cases. Not initializing instance variables to nil can be much better for performance, and redefining methods without removing the method first is the only safe approach in multi-threaded code. There are reasons that you may want to issue verbose warnings by default in these cases. For uninitialized instance variables, it helps catch typos. For method redefinition, it could alert you that a method already exists when you didn't expect it to, such as when a file is loaded multiple times when it should only be loaded once. I propose we keep the default behavior the same, but offer the ability to opt-out of these warnings by defining methods. For uninitialized instance variables in verbose mode, I propose we call `expected_uninitialized_instance_variable?(iv)` on the object. If this method doesn't exist or returns false/nil, we issue the warning. If the method exists and returns true, we suppress the warning. Similarly, for redefined methods, we call `expected_redefined_method?(method_name)` on the class or module. If the method doesn't exist or returns false/nil, we issue the warning. If the method exists and returns true, we suppress the warning. This approach allows high performance code (uninitialized instance variables) and safe code (redefining methods without removing) to work without verbose mode warnings. I have implemented this support in a pull request: https://github.com/ruby/ruby/pull/3371 -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>