Running with Ruby

Tag: Ruby 2.7

The hidden cost of the Ruby 2.7 dot-colon method reference usage

Note: This case is valid also for the “old” #method method usage. The reason why I mention that in the “dot-colon” context, is the fact that due to the syntax sugar addition, this style of coding will surely be used more intensely.


One of the most interesting for me features of the upcoming Ruby 2.7 is the syntax sugar for the method reference. I like using the #method method together with the #then (#yield_self) operator in order to compose several functions in a “pipeline” like fashion. It’s particularly useful when you process data streams or build ETL pipelines.

Here’s an example of how you could use it:

class Parse
  def self.call(string)
    string.to_f
  end
end

class Normalize
  def self.call(number)
    number.round
  end
end

class Transform
  def self.call(int)
    int * 2
  end
end

# Simulate a long-running data producing source with batches
# Builds a lot of stringified floats (each unique)
stream = Array.new(10_000) do |i|
  Array.new(100) { |i| "#{i}.#{i}" }
end

stream.each do |batch|
  batch
    .map(&Parse.:call)
    .map(&Normalize.:call)
    .map(&Transform.:call)
end

It’s nice, it’s clear, it’s short. So what is wrong with it?

Well, what is wrong is Ruby itself. Each time you reference a method using the #method method, Ruby gives you a new instance of a #Method class. Even when you’re fetching the method of the same instance of an object. That’s not all! Since we’re using the & operator, each of the fetched method references is later on converted into a Proc object using the #to_proc method.

nil.:nil?.object_id #=> 47141222633640
nil.:nil?.object_id #=> 47141222626280
nil.:nil?.object_id #=> 47141222541360

# In general
nil.:nil?.object_id == nil.:nil?.object_id #=> false
nil.:nil?.to_proc == nil.:nil?.to_proc #=> false

It means that when you process a lot of data samples, you may spin up a lot of objects and pay a huge performance penalty. Especially when you operate on a per entity basis:

stream.each do |batch|
  batch.each do |message|
    message
      .then(&Parse.:call)
      .then(&Normalize.:call)
      .then(&Transform.:call)
  end
end

If you run the same code as above, but in a way like this:

stream.each do |batch|
  batch.each do |message|
    Transform.call(
      Normalize.call(
        Parse.call(message)
      )
    )
  end
end

you end up having 12 million fewer objects and you will be able to run your code almost 10 times faster!
See for yourself:

require 'benchmark/ips'

GC.disable

class Parse
  def self.call(string)
    string.to_f
  end
end

class Normalize
  def self.call(number)
    number.round
  end
end

class Transform
  def self.call(int)
    int * 2
  end
end

# Builds a lot of stringified floats (each unique)
stream = Array.new(10_000) do |i|
  Array.new(100) { |i| "#{i}.#{i}" }
end

Benchmark.ips do |x|
  x.config(time: 5, warmup: 1)

  x.report('std') do
    stream.each do |batch|
      batch.each do |message|
        Transform.call(
          Normalize.call(
            Parse.call(message)
          )
        )
      end
    end
  end

  # This case was pointed out by Vladimir Dementyev
  # See the comments for more details
  x.report('std-then') do
    stream.each do |batch|
      batch.each do |message|
        message.then do |message|
          Parse.call(message)
        end.then do |message|
          Normalize.call(message)
        end.then do |message|
          Transform.call(message)
        end
      end
    end
  end

  x.report('dot-colon') do
    stream.each do |batch|
      batch.each do |message|
        message
          .then(&Parse.:call)
          .then(&Normalize.:call)
          .then(&Transform.:call)
      end
    end
  end

  x.compare!
end

Results:

Warming up --------------------------------------
         std 1.000 i/100ms
    std-then 1.000 i/100ms
   dot-colon 1.000 i/100ms
Calculating -------------------------------------
         std 6.719 (± 0.0%) i/s - 34.000 in 5.060580s
    std-then 3.085 (± 0.0%) i/s - 16.000 in 5.187639s
   dot-colon 0.692 (± 0.0%) i/s -  4.000 in 5.824453s

Comparison:
         std: 6.7 i/s
    std-then: 3.1 i/s - 2.18x  slower
   dot-colon: 0.7 i/s - 9.70x  slower

Same for the allocation of the objects:

tao1 =  GC.stat[:total_allocated_objects]

stream.each do |batch|
  batch.each do |message|
    Transform.call(
      Normalize.call(
        Parse.call(message)
      )
    )
  end
end

tao2 =  GC.stat[:total_allocated_objects]

stream.each do |batch|
  batch.each do |message|
    message.then do |message|
      Parse.call(message)
    end.then do |message|
      Normalize.call(message)
    end.then do |message|
      Transform.call(message)
    end
  end
end

tao3 =  GC.stat[:total_allocated_objects]

stream.each do |batch|
  batch.each do |message|
    message
      .then(&Parse.:call)
      .then(&Normalize.:call)
      .then(&Transform.:call)
  end
end

tao4 =  GC.stat[:total_allocated_objects]

p "Std allocated: #{tao2 - tao1}"
p "Std-then allocated: #{tao3 - tao2}"
p "Dot-colon allocated: #{tao4 - tao3}"
Std allocated: 1
Std-then allocated: 2
Dot-colon allocated: 12000002

So, shouldn’t we use the new feature (and method reference in general) at all? Not exactly. There are two things you need to do if you want to use it and not slow down your application that much.

Memoize your method references

Instead of fetching the method reference for each of the objects (or batches), fetch it once and re-use:

parse = Parse.:call
normalize = Normalize.:call
transform = Transform.:call

stream.each do |batch|
  batch.each do |message|
    message
      .then(&parse)
      .then(&normalize)
      .then(&transform)
  end
end

This will save you from creating 3 milions objects and will make your code 7 times slower than the base one.

Convert the memoized methods into procs

Since Ruby will do that for you anyhow (in a loop), why not be smarter and do it for him:

parse = Parse.:call.to_proc
normalize = Normalize.:call.to_proc
transform = Transform.:call.to_proc

stream.each do |batch|
  batch.each do |message|
    message
      .then(&parse)
      .then(&normalize)
      .then(&transform)
  end
end

This will make the code above only 2.5 times slower than the base one (usually it’s fine), and at the same time, it will save you almost all out of the 12 milion additional objects!

Dot-colon and the method reference further development

Some of you might know that I’ve been involved a bit in this feature. I proposed and submitted a patch, that will make the .: Method object frozen. It may seem like not much, but freezing keeps a window of opportunity for introducing method reference caching in case it would be needed because the method object is immutable.

This proposal was an aftermath of my discussion with Ko1 and Matz this summer in Bristol. When using the #method method (not the syntax-sugar), due to the backwards compatibility (that I hope will be broken in this case), the Method instance is not frozen. However, the .: will be. It’s a rare corner case (why would you even want to mutate an object like that?), but it does create a funny “glitch”:

nil.:nil? == nil.method(:nil?) #=> true
nil.:nil?.frozen? #=> true
nil.method(:nil?).frozen? #=> false

Note: I’m planning to work on adding the last-method cache after the 2.7 is released and after I’m able to statistically justify that the majority of cases are as those presented above.


Cover photo by Rahel Samanyi on Attribution 2.0 Generic (CC BY 2.0) license.

Ruby 3 gathering/hack challenge summary

Many of you may not be aware, but Ruby 3 is not only a distant, abstract concept. Ruby 3 is an end goal of a process that is already pretty advanced.

This week I had a chance to participate in a non-public Ruby 3 gathering/hack challenge that was organized by Miles Woodroffe and Cookpad in Bristol.

The goal of events like this one is to gather Ruby core team members as well as many of the prominent Ruby community developers and speakers in one place, to present Ruby 3 work progress, other Ruby improvements, gather feedback, exchange ideas and learn.

People see Ruby as a language that is being developed in separation from the community outside of Japan. It’s hard for me to make an opinion on this, as even with how things are now, it’s not that hard to keep track of all of the changes. However, I do believe, that gatherings like one in Bristol bind the community together, especially since they do connect core Ruby developers with people that are building many of the Ruby ecosystem components.

In this article, I will try to cover for you some of the things that happened as well as some of my opinions on the state of Ruby 2.7 and Ruby 3.

Organization

The event was divided into three main parts:

  • Workshops – hacking Ruby 2.7 with all the current development improvements and fixing or reviewing some of them in details
  • Presentations – Presentations from Ruby core team members on their recent work related to Ruby future
  • Discussions – Open discussions amongst all the guests

Workshops

Did you ever play “Throw & Catch” with Matz? ;)

Workshops form was pretty much open. You could pick whether you would prefer to play with the new features or rather spend time discussing selected improvements with core members.

I’ve decided to spend time working on the optimizations of the method #method Method object. I do a lot of #method related pipelined operations in a manner like that:

class TrBase
  def self.call(input)
    data = input.dup
    data[data.keys[0] + to_s] = data.delete(data.keys[0])
    data
  end
end

A = Class.new(TrBase)
B = Class.new(TrBase)
C = Class.new(TrBase)
D = Class.new(TrBase)

stream.each do |data|
  data
    .freeze
    .then(&A.:call)
    .then(&B.:call)
    .then(&C.:call)
    .then(&D.:call)
end

However, not many people know that under the hood, a code as above might create hundreds of thousand objects per second when the data-sets are big enough. I worry that, with a new syntax-sugar, people will use this approach more often, thus sometimes slowing their code a lot just by not understanding what is going on under the hood.

I’ve been working with Koichi-san on introducing internal method cache for the “dot colon” method references. I will write a separate blog post about that soon and explain why in the end it was not merged into Ruby and what we can do to countermeasure that issue.

Apart from that, I’ve been working on dry-monitor with Anton Davydov as it is really rare to be able to meet him and Solnic the same time, in the same place. We did a lot of conceptual work that will allow for shipping some exciting features in the future.

Presentations

There were four presentations:

  1. Keynote from Matz
  2. Types in Ruby from Yusuke Endoh (Mame)
  3. Concurrency improvements and future concurrency models for Ruby by Koichi Sasada’s
  4. Compacting GC in Ruby 2.7by Aaron Patterson

“Nothing new” one may say. Many of the things presented were already announced or introduced during various conferences before. What was different is the fact that the core members had way more time to answer questions and to get involved in discussions.

Due to the type of work that I do in Castle, and my OSS I was in particular interested in new concurrency models for Ruby.

Koichi-san presented concepts like Auto-Fibers, Threadlets, Guilds / Isolates as well as ideas on where and when each of them could be used. If at least part of the solution hits Ruby 3.0, we might see significant performance boosts for many things.

Discussions

Here are things that I did consider significant that were discussed:

  • Matz is aware of the “pipeline operator problem.”
  • Matz calls it a chain operator, and he is considering either changing the syntax or postponing this change at all.
  • Matz does not believe that more ways of expressing the same concepts in the language increase its entropy.
  • Matz is against deprecating by “gemifying” non-syntax potential incompatibilities (see ERB old and new API).
  • Guilds API is not stable; thus, for now, there is no way to mimic that feature with threads.
  • Ko1s Guilds API Ruby branch is not workable, and the progress on Guilds is not too fast.
  • Global Object Space is a problem for Guilds in the context of memory allocation.
  • There is no way to assess memory fragmentation without taking dumps. Noah Gibbs suggested a solution that could allow cheap runtime estimation of that value. However, I did not yet verify his idea.
  • Gradual Write Barrier insertion should allow further memory optimizations while maintaining compatibility with the C API.

Summary

It is worth keeping in mind that one of the things that make Ruby a productive tool is the availability of libraries and pre-brewed solutions.

Gatherings like this one allow libraries creators and maintainers to get a bit more insight on current and future development of features and improvements that could be used to build up even more amazing libraries.

At the moment, I’m disappointed only about the fact that Guilds API is not yet ready even as a concept. I do understand the reasons, but having “more or less” frozen API would allow me to mimic it with native threads and make things like Karafka “Guilds ready”™. Without such a piece of information, none of the lib builders knows what to expect. I do fear, that if Guilds are not being presented upfront, we might end up having Ruby 3 with a feature, that won’t be supported by the majority of the main libs for a long time.

After the gathering, I also don’t share Paweł Świątkowski worries that much anymore.

For example, what he calls an NIH syndrome is in my opinion more of a cautious approach towards building things that will have to be maintained for a long time (and knowing Matz approach – probably forever).

There shouldn’t be a single component of the language, that couldn’t be debugged or fixed by at least one of the core members. It applies to things like GC, Memory allocators but also any new stuff like pattern matching. In the end, who would want things that could break Ruby but that couldn’t be fixed fast enough? Same applies to the chain operator (that, in my opinion, is useless).

Is Ruby on a good road to become something more than it is now? Definitely yes, however, it is a bumpy one with many challenges on the horizon.

Copyright © 2019 Running with Ruby

Theme by Anders NorenUp ↑