I suspect that this kind of performance issue may be fixed by better compiler optimisation in the future (I think should be possible for the compiler to notice that the string doesn't escape and pass a pointer to the byte slice as the string argument).
On 15 September 2017 at 10:36, Peter Waller <pe...@pdftables.com> wrote: > Because of the immutability of the string, constructing a string on a byte > slice requires allocating and copying the bytes. Once you've got the string, > it's "free" to pass around. > > If you've already got strings, everything is fine. But if you're reading the > data from IO, you're probably starting with bytes, and if you can avoid the > allocs, it means less GC pressure. YMMV, but I have seen performance wins of > 2-5x by avoiding string allocations in a data parse heavy loop (Atoi being > one place where strings are allocated). > > On 15 September 2017 at 06:26, as <as.u...@gmail.com> wrote: >> >> Strings are immutable, slices arent. Doesnt this make a string the optimal >> read only data structure for storing and passing around a run of bytes? >> >> If there is performance data, please share. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
