[ruby-core:72525] [Ruby trunk - Bug #11901] Performance Issue with OpenStruct

[ariel.caplan@mail.yu.edu]

Issue #11901 has been updated by Ariel Caplan.


Now, to throw in my own opinion: probably the simplest fix would be to circumvent the `#respond_to?` check if we hit `#method_missing?` already - the check is both unnecessary and inaccurate.  So probably we'd want the method defining methods to be its own method, and then have both `#method_missing?` and `#new_ostruct_member` rely on that.  Something like:

``` ruby
class OpenStruct
  def new_ostruct_member(name)
    name = name.to_sym
    unless respond_to?(name)
      define_openstruct_methods(name)
    end
    name
  end

  def define_openstruct_methods(name)
    define_singleton_method(name) { @table[name] }
    define_singleton_method("#{name}=") { |x| modifiable[name] = x }
    name
  end

  def method_missing(mid, *args) # :nodoc:
    len = args.length
    if mname = mid[/.*(?==\z)/m]
      if len != 1
        raise ArgumentError, "wrong number of arguments (#{len} for 1)", caller(1)
      end
      modifiable[define_openstruct_methods(mname)] = args[0]
    elsif len == 0
      if @table.key?(mid)
        define_openstruct_methods(mid)
        @table[mid]
      end
    else
      err = NoMethodError.new "undefined method `#{mid}' for #{self}", mid, args
      err.set_backtrace caller(1)
      raise err
    end
  end
end
```

Running the previously attached benchmark prefaced with this code, the "assigned on initialization" benchmark outperforms the "assigned after initialization" one.

However, it does raise the question: Should calling `#foo=` define the methods actively, or should we only try to define on `#foo` to match lazy behavior on the initializer?

----------------------------------------
Bug #11901: Performance Issue with OpenStruct
https://bugs.ruby-lang.org/issues/11901#change-55789

* Author: Ariel Caplan
* Status: Open
* Priority: Normal
* Assignee: Marc-Andre Lafortune
* ruby -v: ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin13]
* Backport: 
----------------------------------------
After recent changes to define OpenStruct getter/setter methods lazily, there is a heavy performance impact for the use case where an attribute is assigned at initialization time (i.e. `Openstruct.new(foo: :bar)`).  Once an attribute is stored in the internal hash, the appropriate singleton methods will never be defined, due to the recent changes to OpenStruct's `#respond_to_missing?` - meaning that every time I call `#foo` or `#foo=` it relies on `#method_missing`.  Benchmark using benchmark-ips is attached.

I'm primarily concerned about the case of configuration objects, which may be populated at initialization time and then accessed many times throughout the life of the program.

---Files--------------------------------
openstruct-regression-benchmark.rb (1.36 KB)


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