On Mon, Jul 11, 2016 at 3:28 PM, Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Jul 11, 2016 at 3:49 AM, Manlio Perillo
> <manlio.peri...@gmail.com> wrote:
>> Il giorno domenica 10 luglio 2016 04:51:21 UTC+2, Ian Lance Taylor ha
>> scritto:
>>>
>>> On Sat, Jul 9, 2016 at 4:38 PM, Erich Rickheit KSC <rick...@numachi.com>
>>> wrote:
>>> > I found myself writing code like this:
>>> >
>>> > s := make([]byte, len)
>>> > for i := 0; i < len; i++ {
>>> > // fill in s with stringy goodness
>>> > }
>>> > return string(s)
>>> >
>>> > Does this reuse the memory in s for the string, or does it allocate new
>>> > memory and copy? Or does escape analysis swoop in and make that
>>> > decision?
>>>
>>> This will normally allocate new memory for the string and copy over
>>> the bytes. I believe that the compiler could optimize this case, but
>>> as far as I know no Go compiler currently implements that
>>> optimization.
>>>
>>
>> Since the compiler can already tell that s does not escape the function,
>> what is the additional complexity for this optimization?
>
> Making sure that s is not modified after the conversion to string.
> That could happen in fairly subtle ways even if the slice is known to
> not escape, as in
> s2 := append(s, 0)
> str := string(s)
> s2[0] = 1
>
Right, thanks.
However, a quick search for "return string(" reveals that a lot of
code in the standard library use this pattern.
In order to enable this optimization the compiler only needs to check
that s is not referenced inside a closure, AFAIK.
Manlio
--
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.
