Returns an Array (...)

This can actually be put on Indexable to improve all indexable collections instead of just tuple.

Doing this means you can remove Deque#to_a too, and I'd rather you copied Deque#to_a's implementation using each and preallocating the size than this code which does a bounds-check on every self[i].

Of course, benchmarking after this change would be required. (and maybe investigate using this code but using self.unsafe_at too, to see if there's better performance)

require "benchmark"

module Enumerable
  def to_aa
    ary = Array(T).new(size)
    each { |e| ary << e }
    ary
  end
end

struct Tuple
  def to_a1
    Array(Union(*T)).new(size) do |i|
      self[i]
    end
  end

  def to_a2
    arr = Array(Union(*T)).new(size)
    {% for i in 0...T.size %}
      arr << self[{{i}}]
    {% end %}
    arr
  end
end

t = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, "a" }
Benchmark.ips do |x|
  x.report("to_a") { t.to_a }
  x.report("to_aa") { t.to_aa }
  x.report("to_a1") { t.to_a1 }
  x.report("to_a2") { t.to_a2 }
end

output:

 to_a   1.37M (732.25ns) (± 4.60%)  1.51× slower
to_aa   2.04M (489.27ns) (± 9.49%)  1.01× slower
to_a1   1.65M (606.33ns) (± 3.47%)  1.25× slower
to_a2   2.06M ( 485.6ns) (± 8.03%)       fastest

Conclusion: Skipping optimizing Tuple#to_a, will just preallocate the size of the array in Enumerable#to_a

Please don't use size in Enumerable#to_a, because size traverses the enumerable, so you'll end up traversing it twice.

Let's preallocate in Indexable and Tuple, but leave Enumerable#to_a as is.

Thanks!

ok

but @asterite don't you think that counting (which only happens if the class doesn't implement their own size method) still might be faster than dynamically growing an array?

No idea.

@carlhoerberg I guess that depends on the implementation of the Enumerable. We should assume it's cost intensive by default and use a faster algorithm where size is trivial (like in Indexable).

Please run formatting (crystal tool format) also for the example code:

{1, 2, 3}.to_a # => [1, 2, 3]

Thank you.

The optimizer should make this into a single memcopy for indexable with the elements in sequence, right?

I don't think so. The optimizer is pretty dumb.

If this ends up as a bottleneck in any specific class, there's plenty of scope for overriding it to use memcpy in classes where that's possible.