I seriously doubt that it's actually going to make anything faster in
reality. I bet that a) copying one word or three words doesn't actually
make any observable difference, but b) it's not going to actually help a
lot, because in most cases you will need to copy the indirected struct
anyway and c) the performance hit of this additional indirection will more
than offset any potential wins.
I might be wrong (I'm just guessing here), but it's a naive claim to make,
that this is better and would need some benchmarking, in any case.
On Fri, Mar 3, 2017 at 11:48 AM, T L <tapir....@gmail.com> wrote:
>
>
> On Saturday, March 4, 2017 at 12:47:10 AM UTC+8, T L wrote:
>>
>>
>>
>> On Friday, March 3, 2017 at 10:32:25 PM UTC+8, Ian Lance Taylor wrote:
>>>
>>> On Fri, Mar 3, 2017 at 5:31 AM, T L <tapi...@gmail.com> wrote:
>>> >
>>> > On Friday, March 3, 2017 at 7:52:42 PM UTC+8, Ian Davis wrote:
>>> >>
>>> >> Perhaps you can help the discussion by explaining the advantages you
>>> see
>>> >> in that change?
>>> >
>>> >
>>> > The advantage is to save a few bytes memory and make faster copying.
>>>
>>> I don't see how the suggestion saves memory. Currently, we can
>>> represent a string or slice with a single allocation. Your suggestion
>>> would require us to use two allocations: one for the bytes, and one
>>> for the structure pointing to the bytes. In some cases escape
>>> analysis would eliminate that second allocation, but not in all.
>>>
>>> Ian
>>>
>>>
>> Yes, the suggestion needs more allocations in creating new string and
>> slice values.
>> But it makes copying string and slice values a little faster and a little
>> less memory consuming.
>>
>>
> And yes, avoid one more memory allocation is a good reason to reject the
> suggestion. :)
>
>
>>
>>
>>>
>>> >> On Fri, 3 Mar 2017, at 11:44 AM, T L wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Friday, March 3, 2017 at 4:27:02 PM UTC+8, Konstantin Khomoutov
>>> wrote:
>>> >>
>>> >> On Thu, 2 Mar 2017 23:49:52 -0800 (PST)
>>> >> T L <tapi...@gmail.com> wrote:
>>> >>
>>> >> > After all, the len and cap fields of any value of string and slice
>>> >> > values are immutable.
>>> >>
>>> >> Could you elaborate?
>>> >>
>>> >> Are you suggesting to replace
>>> >>
>>> >> var s []string
>>> >>
>>> >> if len(s) ...
>>> >> if cap(s) ...
>>> >>
>>> >> with
>>> >>
>>> >> if s.len ...
>>> >> if s.cap ...
>>> >>
>>> >> ?
>>> >>
>>> >> If yes, then what would be the prospective benefits?
>>> >>
>>> >>
>>> >>
>>> >> No, I mean why not define string and slice as
>>> >>
>>> >> type string struct {
>>> >> underlyingString *struct {
>>> >> data *byte
>>> >> len int
>>> >> }
>>> >> }
>>> >>
>>> >> type slice struct {
>>> >> underlyingSlice *struct {
>>> >> underlyingElements unsafe.Pointer
>>> >> len int
>>> >> cap int
>>> >> }
>>> >> }
>>> >> instead of the current:
>>> >>
>>> >> type string struct {
>>> >> data *byte
>>> >> len int
>>> >> }
>>> >>
>>> >> type slice struct {
>>> >> underlyingElements unsafe.Pointer
>>> >> len int
>>> >> cap int
>>> >> }
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> 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...@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...@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.
