IMO @io << @quote_char << @quote_char in one line is clearer

But @Sija wouldn't @io << @quote_char << @quote_char be faster? Because it's one operation then instead of two. I also made a benchmark:

require "benchmark"

Benchmark.ips do |x|
  x.report "2 operations" {
    io1 = IO::Memory.new 
    io1 << "hello"
    io1 << "hello"
  }

  x.report "1 operation" {
    io2 = IO::Memory.new 
    io2 << "hello" << "hello"
  }
end

crystal file.cr --release

This gives the results:

2 operations   4.45M (224.91ns) (±10.23%)  1.06× slower
 1 operation   4.72M (211.66ns) (± 9.68%)       fastest

fair 'nuff, changed.

no????

the two are exactly the same, << just returns self.

God I wish I had a desktop to benchmark on instead of a laptop, the results are always terribly noisy, and the last result always wins. We should do some order randomization and result splicing in the benchmark harness to attempt to combat this

Doesn't the one line yield Builder.new(io, separator, quote_char) works?

This PR is not about that, sorry.

Please, let's stop commenting about syntax. Let's focus on semantic. Same line, different line, it's the same behaviour.

This is not about syntax here, it's about avoiding an uneeded memory allocation

??

I'm probably wrong sorry, but builder = allocates, right? Avoiding this and directly yield can improve performance?

No. Builder.new allocates heap memory and puts a reference to it on the stack. That piece on the stack is just called builder. You can call it whatever you want or don't give it any name - it makes no real difference.

A case condition is a bit overkill here.
Smaller to write return true if [@separator, @quote_char, '\n'].includes? byte.unsafe_chr

... but slower

Thanks @straight-shoota I didn't know that, noted! Why case is more perfomant, because the includes use an Array?

Array#includes? needs to setup and execute a loop and several function calls... not even considering the array allocation. While you could use a tuple instead and LLVM will probably optimize some of this, there is still a considerable overhead over a case ... when which simply translates to a few comparisons.