de: lazily allocate for string decoding

[djc]

@vshashi01 how does this compare in your benchmarks to your previous implementation?

Depending on how common it is to have long strings, a hybrid approach (with an early return only for short inputs) might be better still, I suppose.

[vshashi01]

This looks cleaner indeed, let me pull and run my benchmarks tomorrow and let you know

[vshashi01]

This looks like a cleaner improvement indeed, between the original version and this version flamegraph only shows a 1% variance in execution time within the iterator.

Original (by me)

Flamegraph

Overall execution times for my benchmarks:

New version

Flamegraph

Overall execution times for my benchmarks

I think we can say it is identical within run to run variance expected in performance.

[djc]

Thanks for benchmarking!