Possible perf improvement

[nicholas-l]

I am not sure as to the performance improvements but for reading a long string, there will be a multiple allocations. This is because strings in Javascript are immutable and adding a character to a string causes a new allocation. Instead this change using an Array to temporary aggregate the characters and then at the end, join them together. There seems to be some change in benchmarks but they varied a lot.

[mourner]

Good point! We should definitely look into this, although it will likely only pay off for larger strings. String building in JS is tricky — it's fast up until the string is 12 characters, then it gets slow. See this thread https://twitter.com/mourner/status/973664460291411969

We should probably try some more benchmarks (with different string lengths) to see how this affects performance, and also maybe try buffered concatenation like above.

[kjvalencik]

Agreed. String building is weird in JS. I recently benchmarked some code and was surprised to find that simple string concatenation was nearly twice as fast as allocating a buffer of exactly the correct size and writing into it.

[nicholas-l]

Yes, I noticed this in reading an attribute in a MVT which is a longer string.

[nicholas-l]

This is a pretty unscientific test but this is the difference this pull request makes between the two in panning in Openlayers with a layers which include longer strings in a Vector Tile. Looks like a large reduction in memory allocated for the PBF (see readUTF8 at the top of the first list). Also we could include a check if end > 12 use string concatenation otherwise use arrays but this could be a micro-optimization for Chrome...

[mourner]

@nicholas-l note that profiling like this can be misleading — e.g. V8 has weird optimizations that can change which function allocations are attributed to, but the total size (~7.5MB) looks about the same.

[mourner]

This was addressed in #109 — should be much faster for long strings in the browser now.