Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rubocop Configuration - Phase 2 #61

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Adeynack
Copy link
Contributor

fixes #42

@Adeynack
Copy link
Contributor Author

Adeynack commented Aug 2, 2023

Performance/ChainArrayAllocation

After benchmarking, I decided to NOT enable that cop, because it forces a coding style that feels backwards and in my opinion less clear (multiple lines vs chained-functional-calls), while there actually is an even more memory-efficient alternative.

In short, the cop is forcing this code

a.map(&:to_i).map { _1 % 3 == 0 ? _1 : nil }.compact.take(100)

to be written this way instead

  a.map!(&:to_i)
  a.map! { _1 % 3 == 0 ? _1 : nil }
  a.compact!
  a.take(100)

in order to be more performant.

And more performant it is. Here is a benchmark I wrote that compares them (code at the end of this message). We can see that what the cop suggests allocates 20 240 times less then the pure functional way.

Comparison:
   performance style:       1054 allocated
    functional style:   21333767 allocated - 20240.77x more

However, this is because we are "holding it wrong" most of the times, and because the implementation in Ruby is kind of evil, probably for backwards compatibility reasons.

TL;DR: Use .lazy.

In other languages, those return "iterators" automatically, making the whole thing "lazy". There are no .map creating a whole new array, and .filter creating yet another one. Those return all iterators and each element flows to the end of the chain before things are used, either as iterator, or "re-assembled" in an array or set or hash or whatever is needed.

Now, if we simply start the chain with .lazy, we end up using even LESS memory – 3 times less in fact – while keeping a more readable and concise coding style.

Comparison:
lazy functional style:       1832 allocated
   performance style:       5694 allocated - 3.11x more
    functional style:   21335307 allocated - 11645.91x more

Full code of the benchmark (using GEM benchmark-memory):

# frozen_string_literal: true

source_a = 1_000_000.times.map(&:to_s).to_a

def functional_style(a)
  a.map(&:to_i).map { _1 % 3 == 0 ? _1 : nil }.compact
end

def functional_lazy_style(a)
  functional_style(a.lazy)
end

def performance_style(a)
  a.map!(&:to_i)
  a.map! { _1 % 3 == 0 ? _1 : nil }
  a.compact!
end

Benchmark.memory do |x|
  x.report("functional style") { functional_style(source_a) }
  x.report("performance style") { performance_style(source_a) }
  x.report("lazy functional style") { functional_lazy_style(source_a) }

  x.compare!
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rubocop Configuration - Phase 2
1 participant