Re: [go-nuts] How to cast a multi-value?
On Sun, May 16, 2021 at 7:49 PM 'Marc Michael' via golang-nuts < golang-nuts@googlegroups.com> wrote: > as Go provides multi values I would expect that's possible to cast such a > multi value. Do I see it correctly, that Go does not provide it? > > Example: > > os.ReadFile returns []byte, error. > I want to cast the []byte to a string. > > content, err := os.ReadFile(path) > > Is it possible to cast the []byte directly to a string without using a > second variable? > No, it is not possible to transform the type of one return value in a multi-valued expression such as a function call. Such syntactic sugar would have limited usefulness and, in my opinion, is likely to decrease readability and thus be a source of bugs. If you find yourself needing to perform such conversions so often that such a feature is useful that suggests the APIs you're using need to be changed. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD9m0H-boFwAsGXu5wefwqS7cS6mDEZYbvOB99%2BCEqGHwA%40mail.gmail.com.
[go-nuts] How to cast a multi-value?
Hello, as Go provides multi values I would expect that's possible to cast such a multi value. Do I see it correctly, that Go does not provide it? Example: os.ReadFile returns []byte, error. I want to cast the []byte to a string. content, err := os.ReadFile(path) Is it possible to cast the []byte directly to a string without using a second variable? Kindly regards -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEOc3dWn%3Dn%3DFNaQVhnu56yu9yaoVeJRin_m%2B7DNh8hvqV7Ck%2Bw%40mail.gmail.com.
Re: [go-nuts] Go compiler - syntax tree vs AST?
> As far as I know the most likely next evolutionary step in this area will be to replace the Node tree with the cmd/compile/internal/syntax tree. hello All, I have a question. As far as I know, the AST transformation phase has been in existence for several years now. So I want to know the reason why the AST transformation phase has not been eliminated now? Thanks in advance. 在2019年9月3日星期二 UTC+8 下午11:37:58 写道： > Hello Ian, > > Thank you for your answer. > > Why do you ask? > > > Just out of curiosity, I was working with the SSA package for a tool, and > since the compiler uses this package as well I wanted to go a bit deeper on > that and write a small article on it. That's quite an interesting part but > the usage of two different syntax tree was a bit confusing. > > Hope this helps > > > Yes, a lot. Thanks again! > > Le mardi 3 septembre 2019 17:54:38 UTC+4, Ian Lance Taylor a écrit : >> >> On Tue, Sep 3, 2019 at 6:23 AM Vincent Blanchon >> wrote: >> > >> > The compiler documentation mentions a syntax tree in the parsing phase >> when the AST transformation phase mentions a conversion from the syntax >> tree to the compiler's AST representation. >> > If I do not misunderstand, the command "go tool compile -W" will >> display the AST. >> > >> > I was wondering how far is different the syntax tree from the AST? >> Where could I get documentation or an example of this syntax tree? >> >> Note that AST just means Abstract Syntax Tree, so it's a little >> confusing to talk converting a syntax tree to an AST. What we really >> have is two different ASTs. >> >> Unfortunately none of this stuff is well documented. The parser >> generates a syntax tree as defined in cmd/compile/internal/syntax. >> That is then converted to the Node tree defined in >> cmd/compile/internal/gc/syntax.go. The -W option dumps the latter. I >> don't know of a way to dump the former, but perhaps there is one. >> >> > Also, is this syntax tree mandatory? Is it not possible to build the >> AST directly from the lexer+parser? >> >> The use of two different syntax trees is entirely historical due to >> the evolution of the compiler. The original code base was a C >> compiler written in C which became a Go compiler written in C which >> was machine translated from C to Go. There has been a lot of cleanup >> but there is still a lot of historical cruft. As far as I know the >> most likely next evolutionary step in this area will be to replace the >> Node tree with the cmd/compile/internal/syntax tree. >> >> Hope this helps, and I hope someone will correct me if I made a mistake. >> >> Why do you ask? >> >> Ian >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c765be68-1745-4d98-84b3-7762745cea6en%40googlegroups.com.
Re: [go-nuts] Re: Generics and parentheses
You can use ... As a generic
Chinese 你可以使用 ... 作为泛型标志
在2020年8月26日星期三 UTC+8 上午4:59:41 写道：
> Thanks for the note. Please see the discussion at
> https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ .
>
> Ian
>
> On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian
> wrote:
> >
> > After playing in generics playground with a dozen of cases that came to
> my mind, IMHO brackets seem to be more clear than parentheses for declaring
> type parameters. Also using the type keyword before the type parameter
> reduces the cognitive load drastically.
> >
> > type StateFn[type T] func(T) StateFn[T] // Good
> >
> > vs:
> >
> > type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous
> one
> >
> > It's hard to say if there are any practical alternatives to brackets -
> according to the proposal. But angle brackets are not that ugly by
> themselves.
> >
> > (I'm not sure if this approach is actually possible)
> >
> > The hash/number signs appear in the language specifications just once:
> >
> > type StateFn<#T> func(T) StateFn<#T>
> >
> > And the %T syntax is used to print types:
> >
> > type StateFn<%T> func(T) StateFn<%T>
> >
> > Then, that problematic example would become:
> >
> > a, b = w<#x,y>(z)
> >
> > or:
> >
> > a, b = w<%x,y>(z)
> >
> > On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:
> >>
> >> We have received a variety of feedback on the generics draft design
> (blog). Thanks to everyone who took the time to read it, play with generics
> code in the playground, file issues, and send us their thoughts.
> >>
> >>
> >> Not unexpectedly, many people raised concerns about the syntax,
> specifically the choice of parentheses for type parameter declarations and
> generic type and function instantiations.
> >>
> >>
> >> A typical computer keyboard provides four easily accessible pairs of
> single-character symmetrical "brackets": parentheses ( and ), square
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses
> curly braces to delineate code blocks, composite literals, and some
> composite types, making it virtually impossible to use them for generics
> without severe syntactic problems. Angle brackets require unbounded parser
> look-ahead or type information in certain situations (see the end of this
> e-mail for an example). This leaves us with parentheses and square
> brackets. Unadorned square brackets cause ambiguities in type declarations
> of arrays and slices, and to a lesser extent when parsing index
> expressions. Thus, early on in the design, we settled on parentheses as
> they seemed to provide a Go-like feel and appeared to have the fewest
> problems.
> >>
> >>
> >> As it turned out, to make parentheses work well and for
> backward-compatibility, we had to introduce the type keyword in type
> parameter lists. Eventually, we found additional parsing ambiguities in
> parameter lists, composite literals, and embedded types which required more
> parentheses to resolve them. Still, we decided to proceed with parentheses
> in order to focus on the bigger design issues.
> >>
> >>
> >> The time has come to revisit this early decision. If square brackets
> alone are used to declare type parameters, the array declaration
> >>
> >>
> >> type A [N]E
> >>
> >>
> >> cannot be distinguished from the generic type declaration
> >>
> >>
> >> type A[N] E
> >>
> >>
> >> But if we are comfortable with the extra type keyword, the ambiguity
> disappears:
> >>
> >>
> >> type A[type N] E
> >>
> >>
> >> (When we originally dismissed square brackets, the type keyword was not
> yet on the table.)
> >>
> >>
> >> Furthermore, the ambiguities that arise with parentheses appear not to
> arise with square brackets. Here are some examples where extra parentheses
> are not needed with square brackets:
> >>
> >>
> >> using () using []
> >>
> >> func f((T(int)) func f(T[int])
> >>
> >> struct{ (T(int)) } struct{ T[int] }
> >>
> >> interface{ (T(int)) } interface{ T[int] }
> >>
> >> [](T(int)){} []T[int]{}
> >>
> >>
> >> To test this better understanding, and to get a feel for this
> alternative notation, we will begin to make changes to our prototype
> implementation such that it accepts either parentheses or square brackets
> (only one or the other) in a generic Go package. Those changes will first
> appear as commits to the dev.go2go branch, and eventually in the playground.
> >>
> >>
> >> If square brackets don't lead to unforeseen issues, we have another
> fully explored notation to choose from, which will allow us to make a more
> informed decision.
> >>
> >>
> >> - gri, iant
> >>
> >>
> >> PS: For ambiguities with angle brackets consider the assignment
> >>
> >>
> >> a, b = w < x, y > (z)
> >>
> >>
> >> Without type information, it is impossible to decide whether the
> right-hand side of the assignment is a pair of expressions
> >>
> >>
> >> (w < x), (y > (z))
> >>
> >>
> >> or whether it is a generic function invocation that
[go-nuts] Re: go.mod necessary for GitHub package?
Sorry, I used an incorrect example. The final user is supposed to be in module mode and even if in GOPATH mode, the latest version is still compatible with the old version. On Sunday, May 16, 2021 at 4:04:38 PM UTC+2 Manlio Perillo wrote: > One example (not tested) is the case of a module X that depends on A and B. > A depends on an old version of github.com/speedata/hyphenation, and B > depends on a new version (that is compatible with the old version but has a > new API). > > In GOPATH mode, X can not be built. > > > Manlio > On Sunday, May 16, 2021 at 3:36:53 PM UTC+2 Patrick wrote: > >> OK, but what are the advantages for others? >> >> For my projects I use modules (locally) to have a list of dependencies >> with a checksum so builds could be reproducible. This works for remote >> packages with and without go.mod. What is the actual value for other users? >> Is this about versioning (semantic versioning)? Or is it easier to checksum? >> >> Thanks >> >> Patrick >> >> >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b698e9bc-b07b-441e-a95c-d40da680a658n%40googlegroups.com.
[go-nuts] Re: go.mod necessary for GitHub package?
One example (not tested) is the case of a module X that depends on A and B. A depends on an old version of github.com/speedata/hyphenation, and B depends on a new version (that is compatible with the old version but has a new API). In GOPATH mode, X can not be built. Manlio On Sunday, May 16, 2021 at 3:36:53 PM UTC+2 Patrick wrote: > OK, but what are the advantages for others? > > For my projects I use modules (locally) to have a list of dependencies > with a checksum so builds could be reproducible. This works for remote > packages with and without go.mod. What is the actual value for other users? > Is this about versioning (semantic versioning)? Or is it easier to checksum? > > Thanks > > Patrick > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/341099c0-f419-45ee-8084-88043e7332f5n%40googlegroups.com.
[go-nuts] Re: go.mod necessary for GitHub package?
OK, but what are the advantages for others? For my projects I use modules (locally) to have a list of dependencies with a checksum so builds could be reproducible. This works for remote packages with and without go.mod. What is the actual value for other users? Is this about versioning (semantic versioning)? Or is it easier to checksum? Thanks Patrick -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7a74965f-900a-4148-a91d-b620445e2b68n%40googlegroups.com.
[go-nuts] Re: go.mod necessary for GitHub package?
The advantage of adding a go.mod file is not for you, but for people that will add your package as a dependency. Manlio On Sunday, May 16, 2021 at 8:25:23 AM UTC+2 Patrick wrote: > Hello all, > > I have a small package without any dependencies (besides standard library) > on GitHub. Just a single .go file and a test file. > > Question: do I need a go.mod file? Does it give any advantages over not > having one? > > The package works fine by just importing it. > > Patrick > > (The package is located at https://github.com/speedata/hyphenation ) > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0397ac02-4edd-482c-820d-f23f2b48ccffn%40googlegroups.com.
[go-nuts] Re: Strange benchmark results
On Sunday, May 16, 2021 at 4:46:44 AM UTC-4 Brian Candler wrote: > On Sunday, 16 May 2021 at 08:07:17 UTC+1 tapi...@gmail.com wrote: > >> > you don't provide memory allocation statistics, >> >> There are no surprises in memory allocation statistics so I didn't >> mention them. >> >> > I think it is relevant, because your different functions return slices of > different capacity (i.e. different amounts of memory allocated): > https://play.golang.org/p/3IQzd6J1ADa > > The only functions which allocate exactly the right size of slice are > InsertVerbose and InsertVerbose_b. The others rely on append(), and when > that exceeds the size of the current slice and has to allocate a new one, > it allocates a bit extra space for growing room. > > Therefore, you could be measuring boundary conditions around the size that > append() decides to round your slice up to, combined with amount of garbage > collection overhead for large values of N. > > Aside: larger values like N = 1615119 end up with SIGKILL in the > playground - presumably using too much memory - but run locally: > > N = 1615119 > InsertOneline: cap=2524160 > InsertOneline_Disassemble: cap=2524160 > InsertVerbose: cap=2422678 > InsertVerbose_b: cap=2422678 > InsertVerbose_c: cap=2422784 > I'm aware of this. So I expect that the append implementations (especially the one-line ones) should be slower than InsertVerbose and InsertVerbose_b. This is just a small reason why the one-line implementations should be slower. The main reason is they both allocate twice. The expectation is promised from small Ns, but the benchmarks show it is broken for large Ns. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/29b99aae-2041-48a9-824c-f58fcd05ae02n%40googlegroups.com.
[go-nuts] Re: Strange benchmark results
On Sunday, 16 May 2021 at 08:07:17 UTC+1 tapi...@gmail.com wrote: > > you don't provide memory allocation statistics, > > There are no surprises in memory allocation statistics so I didn't mention > them. > > I think it is relevant, because your different functions return slices of different capacity (i.e. different amounts of memory allocated): https://play.golang.org/p/3IQzd6J1ADa The only functions which allocate exactly the right size of slice are InsertVerbose and InsertVerbose_b. The others rely on append(), and when that exceeds the size of the current slice and has to allocate a new one, it allocates a bit extra space for growing room. Therefore, you could be measuring boundary conditions around the size that append() decides to round your slice up to, combined with amount of garbage collection overhead for large values of N. Aside: larger values like N = 1615119 end up with SIGKILL in the playground - presumably using too much memory - but run locally: N = 1615119 InsertOneline: cap=2524160 InsertOneline_Disassemble: cap=2524160 InsertVerbose: cap=2422678 InsertVerbose_b: cap=2422678 InsertVerbose_c: cap=2422784 -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7ff078be-b3ea-4984-b098-f61498284609n%40googlegroups.com.
[go-nuts] Re: Strange benchmark results
> you don't provide the Go version,
My Go version is Go 1.16.3. (BTW, "go test" really should print Go version
in the first line).
> you don't provide memory allocation statistics,
There are no surprises in memory allocation statistics so I didn't mention
them.
> you only provide results for a single data point.
There are no surprises for small Ns. So I I didn't provide the results for
them.
> I am unable reproduce your result.
At least, you exactly reproduced my first observation: if N is large
enough, the one line implementations are fast as the others.
And you partially reproduced my second observation: the InsertOneline
implementations
run faster for odd Ns than even Ns for large Ns.
On Saturday, May 15, 2021 at 11:49:38 AM UTC-4 peterGo wrote:
> For your sliceinsert microbenchmarks, you don't provide the Go version,
> you don't provide memory allocation statistics, and you only provide
> results for a single data point.
>
> My results for several values of N:
>
> https://play.golang.org/p/WuKmIy_jY20
>
> There are significant differences in CPU performance for different values
> of N, ranging from 1:1 to 2:1 for append versus precise implementations.
>
> I am unable reproduce your result.
>
> Peter
>
> On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> package main
>>
>> import "testing"
>>
>> const N = 1615119
>> // It is strange that if N is large enough,
>> // the one line implementations are fast as the others.
>> // And if N is odd number, the InsertOneline_Disassemble
>> // implementation is about 10% faster than the others.
>>
>> func init() {
>> println(" N =", N)
>> }
>>
>> func InsertOneline(s []int, k int, vs ...int) []int {
>> return append(s[:k], append(vs, s[k:]...)...)
>> }
>>
>> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
>> z := append(vs, s[k:]...)
>> return append(s[:k], z...)
>> }
>>
>> func InsertVerbose(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := make([]int, len(s) + len(vs))
>> copy(s2, s[:k])
>> copy(s2[k:], vs)
>> copy(s2[k+len(vs):], s[k:])
>> return s2
>> }
>>
>>
>> func InsertVerbose_b(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := make([]int, 0, len(s) + len(vs))
>> s2 = append(s2, s[:k]...)
>> s2 = append(s2, vs...)
>> s2 = append(s2, s[k:]...)
>> return s2
>> }
>>
>> func InsertVerbose_c(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
>> s2 = append(s2, s[:k]...)
>> s2 = append(s2, vs...)
>> s2 = append(s2, s[k:]...)
>> return s2
>> }
>>
>> var s1 []int
>> func Benchmark_InsertOneline(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/5
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s1 = InsertOneline(x, k, y...)
>> }
>> }
>>
>> var s1b []int
>> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s1b = InsertOneline_Disassemble(x, k, y...)
>> }
>> }
>>
>> var s2 []int
>> func Benchmark_InsertVerbose(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s2 = InsertVerbose(x, k, y...)
>> }
>> }
>>
>> var s3 []int
>> func Benchmark_InsertVerbose_b(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s3 = InsertVerbose_b(x, k, y...)
>> }
>> }
>>
>> var s4 []int
>> func Benchmark_InsertVerbose_c(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s4 = InsertVerbose_c(x, k, y...)
>> }
>> }
>>
>>
>> The result:
>>
>> $ go test -bench=. -benchtime=3s
>> N = 1615119
>> goos: linux
>> goarch: amd64
>> pkg: a.y/bench/sliceinsert
>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>> Benchmark_InsertOneline-4693 4741509 ns/op
>> Benchmark_InsertOneline_Disassemble-4871 4194142 ns/op
>> Benchmark_InsertVerbose-4764 4627334 ns/op
>> Benchmark_InsertVerbose_b-4 769 4958537 ns/op
>>
[go-nuts] Re: Strange benchmark results
Your benchmark exactly reproduced both of my observations.
On Saturday, May 15, 2021 at 9:15:21 AM UTC-4 Brian Candler wrote:
> With go version go1.16.3 darwin/amd64 (macOS 10.14.6), and after changing
> N/5 to N/2, I can't reproduce either.
>
> $ go test . -bench=. -benchtime=3s
> N = 1615119
> goos: darwin
> goarch: amd64
> pkg: bm
> cpu: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
> Benchmark_InsertOneline-4 8674130473 ns/op
> Benchmark_InsertOneline_Disassemble-4 8484161459 ns/op
> Benchmark_InsertVerbose-4 6964988955 ns/op
> Benchmark_InsertVerbose_b-4 7124882270 ns/op
> Benchmark_InsertVerbose_c-4 7024876656 ns/op
> PASS
> ok bm 23.058s
>
> InsertOneline_Disassemble-4 is about 0.75% slower than InsertOneline-4,
> and both are significantly faster than the others.
>
> On Friday, 14 May 2021 at 23:49:16 UTC+1 peterGo wrote:
>
>> My results:
>>
>> https://play.golang.org/p/o2cGAcpNMkX
>>
>> I can't reproduce your results.
>>
>> Peter
>>
>
>> On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>>
>
>>> package main
>>>
>>> import "testing"
>>>
>>> const N = 1615119
>>> // It is strange that if N is large enough,
>>> // the one line implementations are fast as the others.
>>> // And if N is odd number, the InsertOneline_Disassemble
>>> // implementation is about 10% faster than the others.
>>>
>>> func init() {
>>> println(" N =", N)
>>> }
>>>
>>> func InsertOneline(s []int, k int, vs ...int) []int {
>>> return append(s[:k], append(vs, s[k:]...)...)
>>> }
>>>
>>> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
>>> z := append(vs, s[k:]...)
>>> return append(s[:k], z...)
>>> }
>>>
>>> func InsertVerbose(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := make([]int, len(s) + len(vs))
>>> copy(s2, s[:k])
>>> copy(s2[k:], vs)
>>> copy(s2[k+len(vs):], s[k:])
>>> return s2
>>> }
>>>
>>>
>>> func InsertVerbose_b(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := make([]int, 0, len(s) + len(vs))
>>> s2 = append(s2, s[:k]...)
>>> s2 = append(s2, vs...)
>>> s2 = append(s2, s[k:]...)
>>> return s2
>>> }
>>>
>>> func InsertVerbose_c(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
>>> s2 = append(s2, s[:k]...)
>>> s2 = append(s2, vs...)
>>> s2 = append(s2, s[k:]...)
>>> return s2
>>> }
>>>
>>> var s1 []int
>>> func Benchmark_InsertOneline(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/5
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s1 = InsertOneline(x, k, y...)
>>> }
>>> }
>>>
>>> var s1b []int
>>> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s1b = InsertOneline_Disassemble(x, k, y...)
>>> }
>>> }
>>>
>>> var s2 []int
>>> func Benchmark_InsertVerbose(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s2 = InsertVerbose(x, k, y...)
>>> }
>>> }
>>>
>>> var s3 []int
>>> func Benchmark_InsertVerbose_b(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s3 = InsertVerbose_b(x, k, y...)
>>> }
>>> }
>>>
>>> var s4 []int
>>> func Benchmark_InsertVerbose_c(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s4 = InsertVerbose_c(x, k, y...)
>>> }
>>> }
>>>
>>>
>>> The result:
>>>
>>> $ go test -bench=. -benchtime=3s
>>> N = 1615119
>>> goos: linux
>>> goarch: amd64
>>> pkg: a.y/bench/sliceinsert
>>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>>> Benchmark_InsertOneline-4693 4741509 ns/op
>>> Benchmark_InsertOneline_Disassemble-4871 4194142 ns/op
>>> Benchmark_InsertVerbose-4764 4627334 ns/op
>>> Benchmark_InsertVerbose_b-4 769 4958537 ns/op
>>> Benchmark_InsertVerbose_c-4
[go-nuts] go.mod necessary for GitHub package?
Hello all, I have a small package without any dependencies (besides standard library) on GitHub. Just a single .go file and a test file. Question: do I need a go.mod file? Does it give any advantages over not having one? The package works fine by just importing it. Patrick (The package is located at https://github.com/speedata/hyphenation ) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a285af01-c5b5-4a9e-b083-03bc7ff7c53en%40googlegroups.com.
