On 15 September 2017 at 11:54, roger peppe <rogpe...@gmail.com> wrote:
> 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).
Agreed in principle. Thinking aloud follows.
What if the byte slice changes after string construction? At least once
you've got a string you know that (in principle) it shouldn't be modified,
but if the compiler elides the copy, the consumer of the string could be in
for a surprise.
func foo(s string)
...
bs := []byte{0, 1, 2}
s := string(bs)
bs[0] = 42
foo(s)
To cope with this the compiler would have to be able to prove that the
backing array of the slice isn't modified between the creation of the
string and its use, which maybe it can perhaps do in trivial cases such as
foo(string(bs)), where the passed string does not escape.
--
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.
