From: "luislavena (Luis Lavena)" Date: 2012-09-24T20:47:26+09:00 Subject: [ruby-core:47674] [ruby-trunk - Feature #7035][Assigned] defined? should return cached, frozen strings Issue #7035 has been updated by luislavena (Luis Lavena). Status changed from Closed to Assigned Assignee set to nobu (Nobuyoshi Nakada) % Done changed from 100 to 50 =begin Hello Nobu, I'm seeing this failing on both i386-mingw32 and x86-mingw32: 2) Error: test_defined_impl_specific(TestDefined): ArgumentError: wrong number of arguments (1 for 0) C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/test/ruby/test_defined.rb:91:in `test_defined_impl_specific' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit/testcase.rb:17:in `run' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:650:in `block in _run_suites' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:648:in `each' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:648:in `_run_suites' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:21:in `run' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:767:in `run' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:820:in `run' C:/Users/Worker/Jenkins/workspace/ruby-trunk-x64-build/lib/test/unit.rb:824:in `run' ../test/runner.rb:25:in `
' http://ci.rubyinstaller.org/job/ruby-trunk-x64-test-all/87/console http://ci.rubyinstaller.org/job/ruby-trunk-x86-test-all/90/console =end ---------------------------------------- Feature #7035: defined? should return cached, frozen strings https://bugs.ruby-lang.org/issues/7035#change-29703 Author: headius (Charles Nutter) Status: Assigned Priority: Normal Assignee: nobu (Nobuyoshi Nakada) Category: core Target version: 2.0.0 Yehuda and I have been looking into allocation rates in Rails under both MRI and JRuby, and one of the big standouts is defined? logic returning a new String every time (for success cases). We could think of no reason why defined? needs to return a new String, and neither of us know of any code in the wild that takes the resulting string and modifies it. For systems that use defined? heavily, it would seem best to only ever return the same instance of a cached, frozen String, rather than a new String every time that is only used for its boolean-ness and thrown away. Eliminating these extra Strings would reduce allocation and GC burden on MRI, with only the tiniest behavioral change nobody will ever notice. An alternative with a larger behavioral change would be to have defined? always return Symbol, rather than String. The additional danger here is if anyone is using the String result as a String for comparison purposes, which I have definitely seen in the wild. In any case, I could come up with no justification for returning a new String every time, so I have implemented the cached, frozen logic in JRuby: https://github.com/jruby/jruby/commit/b03d0bc89aefca13deaff7a568e5d9118a9ca2a8 -- http://bugs.ruby-lang.org/