Cool.
BTW, there is another docs generator: https://github.com/go101/gold
(written by me).
On Thursday, February 6, 2020 at 7:56:15 PM UTC-5 Trevor Slocum wrote:
> Repository: https://gitlab.com/tslocum/godoc-static
>
> Demo output: https://docs.rocketnine.space
>
> Inspired by the recent news
What should happen after the method is added?
Will those types implementing the interface still implement it?
On Thursday, September 10, 2020 at 6:44:29 PM UTC-4 va...@selfip.ru wrote:
> Hi! Does go support adding method to exiting interface via reflect?
> Mostly I need to add method to struct po
Is it good to introduce owner transfer based string<->[]byte conversions?
After the conversion, the being converted string/[]byte values mustn't be
used any more.
Such as
tlsCertData, _ = ioutil.ReadFile("/etc/ssl/mycert")
var tlsCert string = bultin.ByteSlice2String(tlsCertData)
// forbid usin
There is a prerequisite to transfer ownership: it must be proved that
no other values share ownership of the byte slice returned by
ioutil.ReadFile.
On Saturday, September 12, 2020 at 3:42:14 AM UTC-4 tapi...@gmail.com wrote:
> Is it good to introduce owner transfer based string<-&
package main
import (
"fmt"
"reflect"
)
func main() {
f()
}
func f() {
type S []S
var a, b S
a = S{0: b}
b = S{0: a}
fmt.Println(reflect.DeepEqual(a, b))
}
Now it prints false. But it looks the docs indicates it should print true.
--
You received this message because you are
a}
> fmt.Println(reflect.DeepEqual(a, b))
>
> On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner
> wrote:
>
>> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>>
>> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com
>> wrote:
&
a}
> fmt.Println(reflect.DeepEqual(a, b))
>
> On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner
> wrote:
>
>> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>>
>> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com
>> wrote:
&
instead of sharing the same underlying types with some types?
--
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 th
%5B%5Dbyte-arguments>.
This might be good for some scenarios.
On Friday, September 18, 2020 at 1:31:10 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, Sep 18, 2020 at 10:07 AM tapi...@gmail.com
> wrote:
> >
> > instead of sharing the same underlying types with some types?
>
&g
IMO, the bar function is cleaner and more readable than the foo function.
How do you think?
func foo() {
if vs := f(); len(vs) == 0 {
} else {
for _, v := range vs {
}
}
if vs := f(); len(vs) == 0 {
} else {
s
On Tuesday, October 6, 2020 at 1:54:16 PM UTC-4 Ian Lance Taylor wrote:
> On Tue, Oct 6, 2020 at 10:28 AM tapi...@gmail.com
> wrote:
> >
> > IMO, the bar function is cleaner and more readable than the foo
> function.
> > How do you think?
> >
> >
.
--
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
ober 8, 2020 at 10:58:48 AM UTC-4 tapi...@gmail.com wrote:
>
> .
--
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...@googlegr
For example, some local memory allocations could be detected no used
elsewhere so that they can may be freed immediately when out of reach
instead of waiting to be freed in the GC phase.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsub
be misunderstanding what you're suggesting, but I believe Go already
> tries to detect when a value can be placed on the stack. Then, it will be
> freed automatically when it falls out of scope.
>
> On Sun, Nov 15, 2020 at 5:20 PM tapi...@gmail.com
> wrote:
>
>>
&
For example, by adding two new built-in functions: alloc and free, garbage
collector will ignore the memory allocated by alloc. The memory allocated
by alloc must be freed by calling the free function manually.
This would relieve the burden of GC for some Go programs (such as games).
--
You r
Taylor wrote:
> On Sun, Nov 15, 2020 at 5:38 PM tapi...@gmail.com
> wrote:
> >
> > For example, by adding two new built-in functions: alloc and free,
> garbage collector will ignore the memory allocated by alloc. The memory
> allocated by alloc must be freed by calling th
On Monday, November 16, 2020 at 5:19:59 AM UTC-5 Jan Mercl wrote:
> On Mon, Nov 16, 2020 at 11:14 AM 陶青云 wrote:
>
> > FYI
> > https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/
>
> A CGo-free manual memory allocator might be a better fit sometimes:
> https://godoc.org/mod
y many goroutines at run time,
but at any time point, it is only be used by one goroutine.
>
> On Nov 15, 2020, at 7:34 PM, tapi...@gmail.com wrote:
>
>
>
> Aha, I forgot this fact. You are totally right.
>
> It is a bad example. A better example: is it possible to detect
ve not a
clear thought on this yet.
>
> On Nov 16, 2020, at 8:02 AM, tapi...@gmail.com wrote:
>
>
>
>
>
> On Sunday, November 15, 2020 at 10:24:05 PM UTC-5 ren...@ix.netcom.com
> wrote:
>
>> It is the same. If it can escape the allocation frame you nee
On Monday, January 4, 2021 at 5:23:06 PM UTC-5 ren...@ix.netcom.com wrote:
> Reading
>
> sync.Map[string]linked.List string
>
> I have no idea what that represents?
>
If you can read
sync.Map[string]chan string
then you can read "sync.Map[string]linked.List string" too.
>
> What if
On Tuesday, January 5, 2021 at 11:31:44 AM UTC-5 Brian Candler wrote:
> Are you trying to make user-defined generic maps look more like built-in
> ones?
>
> map[T1]T2 is hard-coded syntax in go. But so is m[k] for accessing
> elements - and you can't use that in user-defined types anyway.
>
>
On Tuesday, January 5, 2021 at 8:43:44 AM UTC-5 axel.wa...@googlemail.com
wrote:
> On Tue, Jan 5, 2021 at 12:03 PM Anonymous AWK fan
> wrote:
>
>> Why does there need to be a delimiter, there isn't one between chan and
>> int in chan int, which I think is more readable than chan[int].
>>
>
>
On Tuesday, January 5, 2021 at 1:29:01 PM UTC-5 Brian Candler wrote:
> On Tuesday, 5 January 2021 at 18:17:14 UTC tapi...@gmail.com wrote:
>
>> What about if the custom generic function syntax is consistent with built
>> ones?
>> For example:
>>
>> v :=
On Wednesday, January 6, 2021 at 9:40:15 AM UTC-5 Brian Candler wrote:
> On Wednesday, 6 January 2021 at 12:40:24 UTC tapi...@gmail.com wrote:
>
>> func blah[T1]T2 (x T1) T2 { ... }
>>>
>>> x := blah[int]string(123)
>>>
>>
>> I didn'
I think OP the "parameter" in title means "argument" actually.
OP didn't specify how to declare a generic type.
On Wednesday, January 6, 2021 at 9:40:15 AM UTC-5 Brian Candler wrote:
> On Wednesday, 6 January 2021 at 12:40:24 UTC tapi...@gmail.com wrote:
&g
If both the memory addresses of the first bytes are equal, then the fast
route will be selected by comparing their lengths.
Otherwise, byte by byte.
On Wednesday, February 10, 2021 at 5:22:28 AM UTC-5 cuiw...@gmail.com wrote:
> i look into map key compare key about string,it will use runtime·me
Does this mean the "+build go1.N" directive is only intended to cooperate
with Go toolchain 1.N+?
--
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+u
BTW, "go1.15 build" succeeds.
On Thursday, February 18, 2021 at 4:03:50 AM UTC-5 tapi...@gmail.com wrote:
> Does this mean the "+build go1.N" directive is only intended to cooperate
> with Go toolchain 1.N+?
>
--
You received this message because you are su
Thanks for the link.
So "go mod tidy" ignores build tags, and this is intended?
On Thursday, February 18, 2021 at 9:28:53 AM UTC-5 Ian Lance Taylor wrote:
> On Thu, Feb 18, 2021 at 1:06 AM tapi...@gmail.com
> wrote:
> >
> > BTW, "go1.15 build" succeeds.
21 at 02:23:45 UTC Ian Lance Taylor wrote:
>
>> On Thu, Feb 18, 2021 at 3:29 PM tapi...@gmail.com
>> wrote:
>> >
>> > Thanks for the link.
>> > So "go mod tidy" ignores build tags, and this is intended?
>>
>> That is my understanding
https://play.golang.org/p/-GZajVGPWYv
--
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
What I mean is
fmt.Println(v3)
and
fmt.Println(v3.Elem())
print the same thing. Is it an intended design?
On Thursday, February 25, 2021 at 11:11:52 PM UTC-5 Kurtis Rader wrote:
> On Thu, Feb 25, 2021 at 8:01 PM tapi...@gmail.com
> wrote:
>
>>
>> http
Println(p1) //
fmt.Println(p2) // 0xcb6020
fmt.Println(p3) // 0xc9e220
}
On Friday, February 26, 2021 at 1:42:32 AM UTC-5 tapi...@gmail.com wrote:
> What I mean is
>
> fmt.Println(v3)
>
> and
>
> fmt.Println(v3.Elem())
>
> print the same th
it does not panic if v's Kind is not String. Instead, it returns a
> string of the form "" where T is v's type. The fmt package treats
> Values specially. It does not call their String method implicitly but
> instead prints the concrete values they hold.
> On Thursda
1.
func String2ByteSlice(s string) []byte {
return (*[^uint(0) >> 1]byte)(unsafe.Pointer(&s))[:len(s):len(s)]
}
2.
func String2ByteSlice(s string) []byte {
return *(*[]byte)(unsafe.Pointer(&struct{string; int}{s, len(s)}))
}
--
You received this message because you are subscribed to th
Sorry, the first one will get a "type [9223372036854775807]byte larger than
address space" error.
The following code will get the same error
var x *[^uint(0) >> 1]byte
Is this error essential?
On Saturday, February 27, 2021 at 11:00:26 PM UTC-5 tapi...@gmail.com wrote
On Sunday, February 28, 2021 at 8:29:51 AM UTC-5 Ian Lance Taylor wrote:
> On Sat, Feb 27, 2021 at 8:00 PM tapi...@gmail.com
> wrote:
> >
> > 1.
> >
> > func String2ByteSlice(s string) []byte {
> > return (*[^uint(0) >> 1]byte)(unsafe.Pointer(&am
Would be better to use compile flags to control each language features
individually?
--
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...@goog
, for the "//go:embed" directive always requires
importing the "embed" package.
On Tuesday, March 2, 2021 at 6:14:23 AM UTC-5 tapi...@gmail.com wrote:
> Would be better to use compile flags to control each language features
> individually?
>
--
You received this messa
different go versions into one binary - so
>>> which language version to use is part of the module description.
>>> So, no. Putting a language version into `go.mod` seems to be exactly the
>>> right way to do this.
>>>
>>> On Tue, Mar 2, 2021 at 12:21 PM
e variables
> holding the embedded files. So, a go toolchain that is not aware of
> embedding can't possibly compile the code (correctly).
>
> On Tue, Mar 2, 2021 at 2:19 PM tapi...@gmail.com
> wrote:
>
>> What is the difference between "embed" and "i
sorry, the 4th setup reports "//go:embed only allowed in Go files that
import "embed"".
On Tuesday, March 2, 2021 at 8:38:05 AM UTC-5 tapi...@gmail.com wrote:
> > Maybe it shouldn't.
>
> By my knowledge, the version specified in go.mod doesn't prevent
I have two machines, their GOROOTs are different.
I build a binary on one machine then transfer the binary to the other.
It runs well on the machine the binary is produced on, but fails on the
other.
The code reporting the error is
unsafePkg, err := build.Import("unsafe", "", build.FindOnl
r else the root used during the Go
>> build.
>
>
> I don't understand how you expect a binary to find GOROOT otherwise, if
> you don't set the environment variable.
>
> On Tue, Mar 9, 2021 at 6:38 AM tapi...@gmail.com
> wrote:
>
>> I have two machine
On Tuesday, March 9, 2021 at 5:02:34 AM UTC-5 axel.wa...@googlemail.com
wrote:
> On Tue, Mar 9, 2021 at 10:09 AM tapi...@gmail.com
> wrote:
>
>> 1. By the document, it looks it should check the result of `go env
>> GOROOT` firstly, but it doesn't.
>>
&g
On Tuesday, March 9, 2021 at 7:04:17 AM UTC-5 axel.wa...@googlemail.com
wrote:
> On Tue, Mar 9, 2021 at 12:39 PM tapi...@gmail.com
> wrote:
>
>> But isn't assuming GOROOT exists almost equivalent to assuming "go"
>> command exists?
>>
>
> Mayb
The tailscale article
https://tailscale.com/blog/netaddr-new-ip-type-for-go/ mentions a finalizer
trick.
The SetFinalizer docs says the finalizer of an object is not guaranteed to
be run. So the tailscale trick is valid, could I think that an object is
not collected for sure if it has a fina
(sorry, missed a "if")
So if the tailscale trick is valid, could I think that an object is
not collected for sure if it has a finalizer and the finalizer has not run
yet?
On Thursday, March 11, 2021 at 9:42:49 AM UTC-5 tapi...@gmail.com wrote:
>
> The tailscale
Now, to modify a map element, especially the element type is not a basic
type, two hashes are needed to compute. This is often unnecessary and
inefficient. For example:
package main
type T struct{
N int
// ... more fields
}
func main() {
var m = map[stri
embler or benchmarks? Just asking
> because this is, as far as I'm concerned, a job for the compiler, to
> eliminate the overhead automatically - and I could well imagine that it's
> already doing it. There definitely shouldn't be a new language construct
> for this.
>
be an optimization in the compiler, not a
> language-level feature.
>
> On Wed, Mar 17, 2021 at 9:44 PM tapi...@gmail.com
> wrote:
>
>>
>> I found this performance difference by benchmarking the two:
>>
>> func IntAdd(words [][]byte) map[string]int {
>>
Printing a nil slice also get the same output [].
I remembered Rob Pike ever said in an issue thread that this can't be
changed now for compatibility reason.
On Monday, March 15, 2021 at 8:18:46 AM UTC-4 Brian Candler wrote:
> I was slightly surprised to discover that the Print() output for an
On Wednesday, March 17, 2021 at 5:19:55 PM UTC-4 axel.wa...@googlemail.com
wrote:
> On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com
> wrote:
>
>> For simple scenarios, compiler optimizations might be possible.
>> But for some complicate ones, it is hard for compile
Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com
>> wrote:
>>
>>> For simple scenarios, compiler optimizations might be possible.
>>> But for some complicate ones, it is har
It looks such info is not recorded in GOPATH/pkg/mod.
--
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 disc
Ah. I forgot this way. Thanks for the tip!
On Thursday, April 8, 2021 at 11:25:55 AM UTC-4 Jan Mercl wrote:
> On Thu, Apr 8, 2021 at 5:18 PM tapi...@gmail.com
> wrote:
>
> > It looks such info is not recorded in GOPATH/pkg/mod.
>
> Do you mean the import path to r
More immutable value proposals:
https://github.com/go101/go101/wiki/Go-immutable-value-proposal-list
On Sunday, April 11, 2021 at 8:47:31 PM UTC-4 Kurtis Rader wrote:
> This has been formally requested several times. For example:
>
> https://github.com/golang/go/issues/20443
> https://github.com
I often use "go build ./..." command to check if there are compilation
errors. Before ./... included 2+ main packages but now only one. Then the
behavior changes, I accidentally commit and push a 10M binary to the remote
repository.
Is this a intended design?
--
You received this message bec
Sorry, "of" should "if" in title.
On Monday, April 19, 2021 at 9:40:00 AM UTC-4 tapi...@gmail.com wrote:
> I often use "go build ./..." command to check if there are compilation
> errors. Before ./... included 2+ main packages but now only one. Then the
Thanks for the information.
Personally, I think the behavior is hard to predict. The binary should be
only produced when a single path is specified.
On Monday, April 19, 2021 at 10:59:33 AM UTC-4 Brian Candler wrote:
> In short, yes this is as intended, although somewhat obscure. The
> docume
I checked out the kubernetes project at tag v1.20.4.
Then run "go list -deps -json ./... > json,txt" in the project root.
In the produced json.txt file, I notice that the module path for
two packages look not right. The path of a package should be
prefixed with its module path. But the two don't. B
I mean, should package "github.com/Azure/go-autorest/autorest/azure" be in
module "github.com/Azure/go-autorest/autorest/adal"?
And, should package "cloud.google.com/go/compute/metadata"" be in module "
cloud.google.com/go/bigquery"?
On Monday, April 19, 2021 at 12:05:38 PM UTC-4 Brian Candler wr
older threads:
* https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o/m/JMJ0fGqhCgAJ
* https://groups.google.com/g/golang-nuts/c/lEKehHH7kZY/m/gCjjBviJBwAJ
On Thursday, April 29, 2021 at 4:51:43 AM UTC-4 oyvin...@teigfam.net wrote:
> I know from some years ago that go did not have any priority o
func MakeCopy(s []int) []int {10%
r := make([]int, len(s))
copy(r, s)
return r
}
func MakeAppend(s []int) []int {
return append(make([]int, 0, len(s)), s...)
}
func MakeAppend2(s []int) []int {
r := make([]int, 0, len(s))
return append(r, s...)
}
It looks MakeCopy is alw
Different optimizations are applied for them?
The benchmark:
package main
import "testing"
func BoxByte(b byte) interface{} {
return b
}
func BoxInt64(i int64) interface{} {
return i
}
var b0, b1, b2 byte = 0, 128, 255
var d, e, f interface{}
func Benchmark_BoxByte(b *testing.B) {
Yes, I'm aware of this optimization.
But it looks another optimization is applied for boxing bytes.
On Monday, May 10, 2021 at 10:38:39 AM UTC-4 Jan Mercl wrote:
> On Mon, May 10, 2021 at 4:30 PM tapi...@gmail.com
> wrote:
>
>
> https://github.
his help?
>
>
> https://github.com/golang/go/blob/25aff96f4b49842a44253b72472062a6d775231c/src/cmd/compile/internal/gc/walk.go#L841
>
> On Mon, May 10, 2021 at 4:46 PM tapi...@gmail.com
> wrote:
>
>> Yes, I'm aware of this optimization.
>> But it looks an
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("
Sorry, there is a temp tweak, the N/5 should be N/2.
The second conclusion should be:
// And if N is odd number, the InsertOneline
// implementations are about 10% faster than the others.
On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>
> package main
>
> imp
ertOneline-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.
>>
>> Pet
lues
> 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 "testi
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
>From the outputs of the following program,
it looks the stack of a goroutine doesn't shrink immediately.
Will it shrink at some point eventually?
package main
func f(i int) byte {
type T int // avoid f being inline
var a [1<<20]byte // make stack grow
return a[i]
}
func main(){
Go 1.16 doesn't make this.
Is it nornal?
package main
func main(){
panic("abc") // "abc" escapes to heap
}
--
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 g
Thanks for the explanation.
On Friday, May 21, 2021 at 4:16:45 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, May 21, 2021 at 7:46 AM tapi...@gmail.com
> wrote:
> >
> > From the outputs of the following program,
> > it looks the stack of a goroutine doesn't shrink im
got it.
On Sunday, May 23, 2021 at 3:50:10 AM UTC-4 cuong.m...@gmail.com wrote:
> Hi,
>
> It's normal, go1.16 and before is just incorrect for not reporting that
> escaping. See: https://go-review.googlesource.com/c/go/+/284412
>
> Cheers,
> Cuong
>
> On S
In the following code, "make([]T, n)" is reported as escaped.
But does it really always escape at run time?
Does the report just mean "make([]T, n) possibly escapes to heap"?
package main
type T int
const K = 1<<13
const N = 1<<12
var n = N
var i = n-1
func main() {
var r = make([]T, N) //
n(r1[i])
}
func g() []T {
var ts = make([]T, N) // make([]T, N) escapes to heap
return ts
}
On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com wrote:
> In the following code, "make([]T, n)" is reported as escaped.
> But does it really always escape at run time?
ctively constant. It might even just mark
> every `make` with a `var` argument as escaping.
>
> On Sun, May 23, 2021 at 10:51 AM tapi...@gmail.com
> wrote:
>
>> In the following code, "make([]T, n)" is reported as escaped.
>> But does it really always escape at run t
It says both "make([]T, N) does not escape" and "make([]T, N) escapes to
heap" for the slice allocated by g.
On Sunday, May 23, 2021 at 5:05:53 AM UTC-4 Jan Mercl wrote:
> On Sun, May 23, 2021 at 11:01 AM tapi...@gmail.com
> wrote:
>
> > And how to interpr
On Sunday, May 23, 2021 at 5:04:37 AM UTC-4 axel.wa...@googlemail.com wrote:
> On Sun, May 23, 2021 at 11:02 AM tapi...@gmail.com
> wrote:
>
>> And how to interpret the conflicting messages for the following program?
>>
>
> In one case, `g` is inlined, which is s
On Sunday, May 23, 2021 at 5:22:23 AM UTC-4 Jan Mercl wrote:
> On Sun, May 23, 2021 at 11:11 AM tapi...@gmail.com
> wrote:
> >
> > It says both "make([]T, N) does not escape" and "make([]T, N) escapes to
> heap" for the slice allocated by g.
>
&
On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com wrote:
> In the following code, "make([]T, n)" is reported as escaped.
> But does it really always escape at run time?
> Does the report just mean "make([]T, n) possibly escapes to heap"?
>
> pack
On Sunday, May 23, 2021 at 5:42:41 AM UTC-4 tapi...@gmail.com wrote:
> On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com wrote:
>
>> In the following code, "make([]T, n)" is reported as escaped.
>> But does it really always escape at run time?
>> D
g. slower
> programs) than an alternative you would suggest. But it's not productive to
> just black-box poke at escape analysis using toy examples and derive broad
> judgments about the existing heuristics from that.
>
> On Sun, May 23, 2021 at 11:57 AM tapi...@gmail.com
>
entation.
>
> As I said, maybe someone else can. Or maybe you should just try and
> collect data and file an issue, if you want this to change.
>
> On Sun, May 23, 2021 at 12:57 PM tapi...@gmail.com
> wrote:
>
>> I do agree escape analysis is hard and gc is clever enoug
is way. In the meantime, there are other
> avenues you can explore.
>
Yes. I don't expect there must be an answer. I just show some weird things.
Maybe the info is helpful for someone. ;D
>
>
>>
>>
>>>
>>> As I said, maybe someone else can. Or mayb
8: flow: ~r0 = ts:
> ./tl.2.go:19:18: from return ts (return) at ./tl.2.go:20:5
> ./tl.2.go:19:18: make([]T, N) escapes to heap
>
>
> On Sunday, May 23, 2021 at 5:01:38 AM UTC-4 tapi...@gmail.com wrote:
>
>> And how to interpret the conflicting messages for the followin
t;>>>> recommendation would be to collect some data on that, showing that for a
>>>>> useful corpus of Go programs, the heuristics lead to more adverse effects
>>>>> (e.g. slower programs) than an alternative you would suggest. But it's
>>>
does move more memory, but this disadvantage is
compensated by its advantage of spending less time on memclrNoHeapPointers
when N is large.
On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>
> package main
>
> import "testing"
>
> const N = 161511
The profiling results constantly show that more time are spent on
memclrNoHeapPointers if N is a big even integer (1615118) than a big odd
integer (1615119).
On Thursday, May 13, 2021 at 5:07:49 AM UTC-4 tapi...@gmail.com wrote:
> Sorry, there is a temp tweak, the N/5 should be N/2.
&g
ting both to either values slows them down, speeds
> them up, or leaves them the same. You'll know if it's a good idea then.
>
> On Sun, May 23, 2021 at 7:05 PM tapi...@gmail.com
> wrote:
>
>> Thanks for the code link. It looks, new(LargeSizeArray) escapes for
On Tuesday, May 25, 2021 at 6:14:24 AM UTC-4 Delta Echo wrote:
> > It's a parameter name. ...interface{} is the type of that argument,
> variadic in this case indicated by the ellipsis.
>
> You misunderstood my question.
>
> My question was what does `a` refers to?
>
> Like,
> fd - file descript
The benchmark code: https://play.golang.org/p/bC1zO14eNeh
The result:
$ go test -bench=.
goos: linux
goarch: amd64
pkg: example.com/valuecopy
cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Benchmark_CopyBool-410 0.8885 ns/op
Benchmark_CopyByte-4
On Sunday, May 30, 2021 at 12:28:55 AM UTC-4 Kurtis Rader wrote:
> On Sat, May 29, 2021 at 8:50 PM tapi...@gmail.com
> wrote:
>
>> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>>
> ...
>>
> From the benchmark result, it looks
>> * the
gcflags=-S shows the code of copy 3-field and 4-field structs:
// struct{a, b, c int}
0x0034 00052 (valuecopy.go:223)MOVQ$0, "".struct3_0(SB)
0x003f 00063 (valuecopy.go:223)XORPSX0, X0
0x0042 00066 (valuecopy.go:223)MOVUPSX0, "".struct3_0+8(SB)
// struc
at 11:49:47 PM UTC-4 tapi...@gmail.com wrote:
> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>
> The result:
>
> $ go test -bench=.
> goos: linux
> goarch: amd64
> pkg: example.com/valuecopy
> cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.5
10 0.7755 ns/op
>>
>> In other words, it looks there is mutual interference between benchmarks.
>>
>> On Saturday, May 29, 2021 at 11:49:47 PM UTC-4 tapi...@gmail.com wrote:
>>
>>> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>&g
On Monday, May 31, 2021 at 10:07:35 AM UTC-4 axel.wa...@googlemail.com
wrote:
> On Mon, May 31, 2021 at 3:30 PM tapi...@gmail.com
> wrote:
>
>> On Sunday, May 30, 2021 at 12:54:02 PM UTC-4 axel.wa...@googlemail.com
>> wrote:
>>
>>> That is very norma
1 - 100 of 278 matches
Mail list logo
