3 ms·

I was curious what Tony's graph would look like using a SimpleDelegator as he suggested. (using ruby 1.9.3p194) Calculating ---------------------------

I was curious what Tony's graph would look like using a SimpleDelegator as he suggested. (using ruby 1.9.3p194) Calculating ------------------------------------- without dci 68507 i/100ms with dci 24409 i/100ms with delegator 46945 i/100ms ------------------------------------------------- without dci 2240202.4 (±3.2%) i/s - 11235148 in 5.020463s with dci 412445.3 (±3.7%) i/s - 2074765 in 5.037113s with delegator 1018928.4 (±1.6%) i/s - 5117005 in 5.023310s RUBY: require 'rubygems' require 'benchmark/ips' require 'delegate' class ExampleClass def foo; 42; end end module ExampleMixin def foo; 43; end end class ExampleProvisioner < SimpleDelegator def foo; 44; end Benchmark.ips do |bm| bm.report("without dci") { ExampleClass.new.foo } bm.report("with dci") do obj = ExampleClass.new obj.extend(ExampleMixin) obj.foo end bm.report("with delegator") do ExampleProvisioner.new(ExampleClass.new).foo end end

bascule 14y ago
Which is pretty much what you'd expect... making two objects instead of one cuts the speed approximately in half.
urbanautomaton 14y ago
I took a stab at separating out the method dispatch costs from the cost of the #extend call here https://gist.github.com/4436640 https://gist.github.com/4436640. I also tried making a call against an unmodified instance of a completely different class to demonstrate that the global method cache is indeed flushed in MRI by doing a runtime #extend on any object instance. Subtracting the results of different runs like this is pretty questionable, though (the errors accumulate), so the above is to be taken with a pinch of salt.
zem 14y ago
the example in the op was somewhat misleading in that he was extending the object within its initialize method. i think you'd more often want to do a per-object extend dynamically at runtime to simulate something like smalltalk's #become, where the object would be modifying its capabilities and 'type' based on some external input conditions.

bascule 14y ago

Which is pretty much what you'd expect... making two objects instead of one cuts the speed approximately in half.

urbanautomaton 14y ago

I took a stab at separating out the method dispatch costs from the cost of the #extend call here https://gist.github.com/4436640 https://gist.github.com/4436640. I also tried making a call against an unmodified instance of a completely different class to demonstrate that the global method cache is indeed flushed in MRI by doing a runtime #extend on any object instance. Subtracting the results of different runs like this is pretty questionable, though (the errors accumulate), so the above is to be taken with a pinch of salt.

zem 14y ago

the example in the op was somewhat misleading in that he was extending the object within its initialize method. i think you'd more often want to do a per-object extend dynamically at runtime to simulate something like smalltalk's #become, where the object would be modifying its capabilities and 'type' based on some external input conditions.