All committers have signed the CLA.

No problem. I'll add a couple of benchmarks and share the results.

Benchmark before this change:

BenchmarkReplacer-8   	18244922	        61.0 ns/op	      48 B/op	       1 allocs/op

Benchmark after this change:

BenchmarkReplacer-8   	 3793706	       310 ns/op	     176 B/op	       5 allocs/op

Good catch, you are correct. I'll have a think about how to do this more efficiently. It is almost certainly possible to do this during the main for loop as part of the replace function.

Awesome, thanks. Yeah, I wonder if it's possible to just skip the escaping backslash when building the string...

Edit: PS. If you want to add your benchmark to the test file that'd be cool too! For any future changes.

Benchmark after optimisation:

BenchmarkReplacer-8   	10560511	       107 ns/op	      48 B/op	       1 allocs/op

Same number of allocs and bytes per operation. Still a little slower though. I'd be very interested in feedback on clarity.

Still a little slower though.

I hypothesize that it's only slower on the case of JSON input (i.e. input where escapes actually happen). You can vary your input string on the benchmark test and see if that's true.

Still, allocations are the big deal -- which is fixed now -- and the speed decrease is minimal. If that speed decrease is in fact just for escaped inputs, then that's probably totally acceptable.

I have a comment/question I'll inline.

Thanks for working on this!

Oh, and just before we merge, could you post the final benchmarks? Thanks again!

Benchmarks for three different scenarios:

• no_placeholder - simple string
• placeholder - {"json": "object"}
• escaped_placeholder - \{"json": \{"nested": "{bar}"\}\}

BenchmarkReplacer/no_placeholder-8         	100000000	        11.4 ns/op	       0 B/op	       0 allocs/op
BenchmarkReplacer/placeholder-8            	21644844	        53.0 ns/op	      32 B/op	       1 allocs/op
BenchmarkReplacer/escaped_placeholder-8    	10888167	       108 ns/op	      48 B/op	       1 allocs/op

Performance-wise, it's looking good. If we keep it in this range for any remaining, last-minute changes, LGTM!

Benchmarks for: e385e0d

BenchmarkReplacer/no_placeholder-8         	160360214	         7.38 ns/op	       0 B/op	       0 allocs/op
BenchmarkReplacer/placeholder-8            	21445204	        54.8 ns/op	      32 B/op	       1 allocs/op
BenchmarkReplacer/escaped_placeholder-8    	 9841627	       122 ns/op	      48 B/op	       1 allocs/op

Benchmarks for: 681531b

BenchmarkReplacer/no_placeholder-8         	158008672	         7.57 ns/op	       0 B/op	       0 allocs/op
BenchmarkReplacer/placeholder-8            	22138293	        53.8 ns/op	      32 B/op	       1 allocs/op
BenchmarkReplacer/escaped_placeholder-8    	10015346	       122 ns/op	      48 B/op	       1 allocs/op

Many thanks for all the support and patience as I worked through this. I'm in the process of deploying Caddy for a small site at the moment. This should give me a little more experience using the application. As I do, I'll take a look at the open issues and see if anything stands out.