From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 38BEE19E0040 for ; Mon, 28 Dec 2015 00:29:44 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 1B586B5D869 for ; Mon, 28 Dec 2015 01:02:18 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 0622518CC7B5 for ; Mon, 28 Dec 2015 01:02:17 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E82EF1205B1; Mon, 28 Dec 2015 01:02:12 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o10.shared.sendgrid.net (o10.shared.sendgrid.net [173.193.132.135]) by neon.ruby-lang.org (Postfix) with ESMTPS id D92071205AA for ; Mon, 28 Dec 2015 01:02:08 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=dYlnZJ9OjssXZ1W+50lSsAixLaE=; b=agtViBL5kJMcHtJY3c QwOhJJk1O+EGnrG07kG/S+Gw6Dgj8Ofd/jmDcyU1b8Ld2h6EwNXwfErq/CeMqS7Q 4WM/YQgHYc/EjCTvLmJhAiJmyu1ZRi4+FKFPzKNzB/GAiTBcFPA3weElmbEUy2Yi THYftX3+uSlEDKl/1OvnZy5HI= Received: by filter0578p1mdw1.sendgrid.net with SMTP id filter0578p1mdw1.11623.56800B7A40 2015-12-27 16:02:02.501199002 +0000 UTC Received: from herokuapp.com (ec2-54-167-191-127.compute-1.amazonaws.com [54.167.191.127]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id XCZhMxTyTPK2GvmcPH_IFw for ; Sun, 27 Dec 2015 16:02:02.565 +0000 (UTC) Date: Sun, 27 Dec 2015 16:02:02 +0000 From: ariel.caplan@mail.yu.edu To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 47124 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11901 X-Redmine-Issue-Author: amcaplan X-Redmine-Issue-Assignee: marcandre X-Redmine-Sender: amcaplan X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6h988FA1bAEyJhO2sVyOtvbSQf51kXPJAfQr +lpsnlEk9Pn3yIdgfRNitElZ4ti2eN5IFNSCW7BuB/PPjvMFARiYRIxZ0t/W/pJBAC4fXHx8s3jOcR haVw8KVUwidi8PTqcoTqO6pxOySv7hdtTXY/d/7cFlCycP6fCXdZdMhq+A== X-ML-Name: ruby-core X-Mail-Count: 72525 Subject: [ruby-core:72525] [Ruby trunk - Bug #11901] Performance Issue with OpenStruct X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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/