This one I'm not sure : Char + String doesn't look quite good.

Well, we should make it good if it's bad I guess.

Not very important in this case (not a potential tight loop) but the original 3 prints pushed 2 static strings and 1 dynamically allocated string to the output buffer, whereas your change now allocates another dynamic string and eventually pushes it to the output buffer, hence requires a thrown-away allocation.

I also made a benchmark

require "benchmark"

filename = "file.cr"

Benchmark.ips do |x|
  x.report "3 prints" do
    print " - "
    print filename
    print ": "
  end

  x.report "1 print" do
    print " - #{filename}: "
  end
end

and the 1 print is 2 times faster.

3 prints   8.35k (119.77µs) (± 6.16%)  2.30× slower
 1 print  19.17k ( 52.16µs) (± 2.83%)       fastest

What the.... Why is that faster? @ysbaddaden you know?

It's related to IO being flushed, if you use another function call IO stops being the bottleneck:

require "benchmark"

def print2(param); end

filename = "file.cr"

Benchmark.ips do |x|
  x.report "3 prints" do
    print2 " - "
    print2 filename
    print2 ": "
  end

  x.report "1 print" do
    print2 " - #{filename}: "
  end
end

3 prints 442.72M (  2.26ns) (± 4.78%)       fastest
 1 print   6.52M (153.48ns) (± 4.70%) 67.95× slower

Fastest is probably print " - ", filename, ": "

You are right. It's actually faster.

require "benchmark"

filename = "file.cr"

Benchmark.ips do |x|
  x.report "3 prints" do
    3.times do
      print " - "
      print filename
      print ": "
    end
  end

  x.report "interpolation print" do
    3.times do
      print " - #{filename}: "
    end
  end

  x.report "comma print" do
    3.times do
      print " - ", filename, ": "
    end
  end
end

(I used 3.times to have clearer results)

           3 prints   2.47k (404.48µs) (±10.79%)  2.53× slower
interpolation print   5.75k (173.88µs) (±11.99%)  1.09× slower
        comma print   6.25k (160.11µs) (±13.01%)       fastest

But i'm sure there are many more interpolation prints like this. Does that means every interpolation print should be changed to a comma print instead now?

Please, use print " - ", filename, ": " version.

code.delete { |c| {'‸', '༓'}.includes? c } may yield to more performance.

Yep it's 2 times faster.

io << to_s.gsub(/<.+?>/, "").delete(' ') << "-macro" on a single line

you can also do

io << to_s.gsub(/<.+?>/, "").delete(' ') \
    << "-macro"

to continue the appends to io and not create a new one.

nvm, the performance here doesn't really matters as @straight-shoota said.

There's no performance benefit in that I don't see one style wise either.

@j8r Please, stop with those style-related comments. This PR is about perf improvements, not specific code style preferences. Also, such change degrades readability for no reason (other than your preferences).

here are the results

require "benchmark"

Benchmark.ips do |x|
  x.report "one append to io" do
    999.times do
    String.build do |io|
      io << "abc" << "bcd"
    end
    end
  end

  x.report "one append to io with backslash" do
    999.times do
    String.build do |io|
      io << "abc" \
         << "bcd"
    end
    end
  end

  x.report "two appends to io" do
    999.times do
    String.build do |io|
      io << "abc"
      io << "bcd"
    end
    end
  end
end

results:

               one append to io   7.59k (131.82µs) (± 9.25%)  1.10× slower
one append to io with backslash   8.37k (119.44µs) (± 2.14%)       fastest
              two appends to io   8.37k (119.49µs) (± 2.43%)  1.00× slower

I'm wrong on which one is fast @Sija, but you're wrong saying that there are no speed differences.

There's no difference, 131.82 * 0.092 = 12.12, 131.82 - 12.12 = 119.7

I mean, do actually think about what you're doing here, the backslash is gone after the parser phase, it doesn't even affect semantic phase, let alone codegen. So the superficial difference your test shows is between the two variants that are exactly the same and just style, yet the one where there actually is a difference (can optimize out the self return by reusing the local), your tests shows there's no practical one.

Your benchmark result is clearly wrong because the first two examples produce exactly the same AST and LLVM IR. If one is faster than the other, that's because of external influences.

They're all the same even in the results, no point in even arguing about environmental issues these micro benchmarks have.

Pulling << "-macro" into the previous line is an unrelated change. It doesn't really improve performance like the rest.
And I find it is easier to read on a separate line.