This is a competing PR vs#2211 by@CarlosEduR

The idea is that we avoid copying strings to a string buffer when we do not need to.

@CarlosEduR uses a sensible approach that does not require 'deep' changes. This PR is somewhat deeper. Whether this PR is better than#2211 is an open question.

Note that@CarlosEduR checks for the null termination which is unnecessary work. Removing this check could change the story.

partial fix to#1470 Note that@jkeiser's idea is somewhat more involved than what we are doing currently.

Benchmarks on my ARM processor (Apple M2).

partial tweek

In this benchmark, we typically do not have escaped content in strings, but it does happen from time to time. I don't have an exact percentage but it is maybe 20% or 10% of the time that we have escaped content.

Using ./build/benchmark/bench_ondemand --benchmark_filter="partial_tweets<simdjson_ondemand>". Run with sudo to get performance counters.

Main:
best_instructions_per_byte=8.68026 best_instructions_per_cycle=6.57819

@CarlosEduR's PR:
best_instructions_per_byte=9.31405 best_instructions_per_cycle=6.54882

This PR:
best_instructions_per_byte=8.66243 best_instructions_per_cycle=6.5704

find tweet

This is a lucky benchmark where we never have escaped content to worry about.

Using ./build/benchmark/bench_ondemand --benchmark_filter="find_tweet<simdjson_ondemand>". Run with sudo to get performance counters.

Main
best_instructions_per_byte=4.71785 best_instructions_per_cycle=6.34339

@CarlosEduR's PR:
best_instructions_per_byte=4.7256 best_instructions_per_cycle=6.34974

This PR:
best_instructions_per_byte=4.71761 best_instructions_per_cycle=6.34714

Conclusion

It is too early to tell which direction this goes because (1) I only tested on one system and (2) only on two benchmarks.

ARM systems do not have to contend with runtime dispatches, so this is an advantage for this PR, compared to@CarlosEduR's PR. However,@CarlosEduR's PR could do better when runtime dispatching is needed.

@CarlosEduR's PR shows a regression which is possibly caused by the fact that it tries to avoid the copy, fails and then has to fall back on the current code. Even if it only happens one time out of 5 or 10, these unlucky cases could cost you.

@CarlosEduR's PR could be further optimized and the story might change.

Overall, my preliminary results suggest that on Apple Silicon, it is not worth avoiding a write on the string buffer.