[#79914] [Ruby trunk Bug#13282] opt_str_freeze does not always dedupe — normalperson@...
Issue #13282 has been reported by Eric Wong.
4 messages
2017/03/05
[#80140] [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus) — shyouhei@...
Issue #13295 has been updated by shyouhei (Shyouhei Urabe).
5 messages
2017/03/13
[#80362] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— Eric Wong <normalperson@...>
2017/03/26
[email protected] wrote:
[#80368] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— SASADA Koichi <ko1@...>
2017/03/27
On 2017/03/26 15:16, Eric Wong wrote:
[#80205] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint — Eric Wong <normalperson@...>
[email protected] wrote:
4 messages
2017/03/17
[#80213] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint
— Martin J. Dürst <duerst@...>
2017/03/17
Hello Eric,
[#80290] [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch — normalperson@...
Issue #13355 has been reported by normalperson (Eric Wong).
4 messages
2017/03/23
[#80410] Re: [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch
— Eric Wong <normalperson@...>
2017/03/27
[email protected] wrote:
[#80415] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
5 messages
2017/03/28
[#80488] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
4 messages
2017/03/29
[ruby-core:80314] [Ruby trunk Bug#13358] OpenStruct overriding allocate
From:
eregontp@...
Date:
2017-03-24 16:48:09 UTC
List:
ruby-core #80314
Issue #13358 has been updated by Eregon (Benoit Daloze).
nobu (Nobuyoshi Nakada) wrote:
> For what purpose?
> It should be used by `Class#new`, `Kernel#dup`, `Kernel#clone`, and `Marshal.load`.
But not only, after all it is a public and well-known method (many hits on GitHub code search).
Many deserializing libraries will use it,
but also various libraries which need to build an instance without passing in state,
or use it as a way to replicate Class#new without using super like (maybe to use a different initializing method):
~~~ ruby
def self.new(name)
if r = CACHE[name]
r
else
# Could use super(name), but not everybody does
allocate.tap { |obj| obj.send(:initialize, name) }
end
end
~~~
> As it is not called usually, it should take the performance penalty, not `respond_to?`.
I think respond_to? should work and not throw an exception on any Object,
even if not fully initialized, just like say #instance_variable_defined?, #equal? and #object_id.
The performance hit on respond_to? is not significant, it's just an extra NIL_P.
On the other hand, the one on allocate is, and affects every caller of OpenStruct.allocate.
~~~ ruby
require 'benchmark/ips'
require 'ostruct'
class SomeClass
end
Benchmark.ips do |x|
x.report("OpenStruct.allocate") { OpenStruct.allocate }
x.report("Class#allocate") { SomeClass.allocate }
x.compare!
end
class MyOpenStruct
def respond_to_missing?(mid, include_private = false) # :nodoc:
mname = mid.to_s.chomp("=").to_sym
@table&.key?(mname) || super
end
end
os = OpenStruct.new
my = MyOpenStruct.new
Benchmark.ips do |x|
x.report("OpenStruct#respond_to?") { os.respond_to?(:init_with?) }
x.report("MyOpenStruct#respond_to?") { my.respond_to?(:init_with?) }
x.compare!
end
~~~
~~~
Comparison:
Class#allocate: 7783868.7 i/s
OpenStruct.allocate: 3813277.6 i/s - 2.04x slower
Comparison:
OpenStruct#respond_to?: 1752400.3 i/s
MyOpenStruct#respond_to?: 1734649.5 i/s - same-ish: difference falls within error
~~~
@nobu: Can I commit my fix?
It is faster and does not change the semantics of OpenStruct.allocate.
----------------------------------------
Bug #13358: OpenStruct overriding allocate
https://bugs.ruby-lang.org/issues/13358#change-63785
* Author: sitter (Harald Sitter)
* Status: Closed
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
* Backport: 2.2: DONTNEED, 2.3: REQUIRED, 2.4: DONTNEED
----------------------------------------
In https://github.com/ruby/ruby/commit/15960b37e82ba60455c480b1c23e1567255d3e05 OpenStruct gained
~~~ruby
class << self # :nodoc:
alias allocate new
end
~~~
Which is rather severely conflicting with expected behavior as `Class.allocate` is meant to [not call initialize](http://ruby-doc.org/core-2.4.0/Class.html#method-i-allocate). So, in fact, the change made `allocate` of `OpenStruct` do what `allocate` is asserting not to do :-/
For `OpenStruct` itself that isn't that big a deal, for classes inheriting from `OpenStruct` it breaks `allocate` though.
Example:
~~~ruby
require 'ostruct'
class A < OpenStruct
def initialize(x, y = {})
super(y)
end
end
A.allocate
~~~
As `allocate` is alias'd to `new` in `OpenStruct` this will attempt to initialize `A` which will raise an `ArgumentError` because `A` cannot be initialized without arguments.
~~~
$ ruby x.rb
x.rb:4:in `initialize': wrong number of arguments (given 0, expected 1..2) (ArgumentError)
from x.rb:9:in `new'
from x.rb:9:in `<main>'
~~~
OpenStruct at the very least should document the fact that its allocate is behaving differently.
Ideally, `OpenStruct` should not alias allocate at all.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>