Re: [go-nuts] Is there a reason go doesn't use the small string optomization

On Wed, Feb 1, 2017 at 6:35 AM, Ian Lance Taylor wrote: > On Tue, Jan 31, 2017 at 10:26 PM, wrote: >> It would know at string creation time because strings in go are immutable. >> Really these are two types, with duck typing between them. (the programmer >> unless using unsafe or reflection sees

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

Ok that clarifies it for me :) ons 1 feb. 2017 kl 15:29 skrev Ian Lance Taylor : > On Tue, Jan 31, 2017 at 10:08 PM, Henrik Johansson > wrote: > > What makes strings harder than for example []byte? > > Sorry, I'm not sure who you are asking, or, really what you are > asking. []byte doesn't have

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

On Tue, Jan 31, 2017 at 10:26 PM, wrote: > It would know at string creation time because strings in go are immutable. > Really these are two types, with duck typing between them. (the programmer > unless using unsafe or reflection sees them the same) > You have a shortstring type and a string typ

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

On Tue, Jan 31, 2017 at 10:59 PM, Eliot Hedeman wrote: > It may not be the most elegant solution, but you could possibly check for > the high bit set on any pointer during GC. If the high bit is set, you know > for sure that that pointer is not actually pointing to anything, but rather > is data.

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

On Tue, Jan 31, 2017 at 10:08 PM, Henrik Johansson wrote: > What makes strings harder than for example []byte? Sorry, I'm not sure who you are asking, or, really what you are asking. []byte doesn't have a small-slice-optimization either. Ian > On Wed, Feb 1, 2017, 06:15 Ian Lance Taylor wrote

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

>From what i read the top 16 bits in a pointer are generally not completely ignored by the cpu in x86-64 virtual address space: AMD64 Architecture Programmer’s Manual Volume 1 - 2.2.2 64-Bit Canonical Addresses: "Although implementations might not use all 64 bits of the virtual address, they ch

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

Strings are easier than []byte because they are immutable. On Wednesday, February 1, 2017 at 12:08:36 AM UTC-6, Henrik Johansson wrote: > > What makes strings harder than for example []byte? > > On Wed, Feb 1, 2017, 06:15 Ian Lance Taylor > wrote: > >> On Tue, Jan 31, 2017 at 9:10 PM, Eliot Hede

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

It would know at string creation time because strings in go are immutable. Really these are two types, with duck typing between them. (the programmer unless using unsafe or reflection sees them the same) You have a shortstring type and a string type, what determines their type is the length of

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

One problem of using the high bits are that they are only available on 64bit systems. There are however classical ways of remedying this problem. Note that I'm writing this on the top of my mind without any reference to look up, so things might be a bit off. I do, however think the gist of the prob

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

It may not be the most elegant solution, but you could possibly check for the high bit set on any pointer during GC. If the high bit is set, you know for sure that that pointer is not actually pointing to anything, but rather is data. Technically speaking, the top 16 bits of any pointer in x86-6

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

What makes strings harder than for example []byte? On Wed, Feb 1, 2017, 06:15 Ian Lance Taylor wrote: > On Tue, Jan 31, 2017 at 9:10 PM, Eliot Hedeman > wrote: > > I was writing up a proposal about adding the small string > > optimization(putting strings on the heap if they will fit within the

Re: [go-nuts] Is there a reason go doesn't use the small string optomization

On Tue, Jan 31, 2017 at 9:10 PM, Eliot Hedeman wrote: > I was writing up a proposal about adding the small string > optimization(putting strings on the heap if they will fit within the > sringStruct)to the go runtime, and I realized there might be good reason why > this has not been done yet. Are

[go-nuts] Is there a reason go doesn't use the small string optomization

I was writing up a proposal about adding the small string optimization(putting strings on the heap if they will fit within the sringStruct)to the go runtime, and I realized there might be good reason why this has not been done yet. Are there any glaring reasons you can think of? Here