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
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<-&
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
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
.
--
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
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...@goo
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 {
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?
> >
> >
%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
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
gt; 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:
>>
>>
gt; 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
may 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:
>
>>
>&g
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
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
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:
>
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
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't see
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
package allocate
import "testing"
import "os"
import "fmt"
func init() {
fmt.Println("OS page size:", os.Getpagesize())
}
var r1 []byte
func BenchmarkCount1(b *testing.B) {
for i := 0; i < b.N; i++ {
r1 = make([]byte, 32768+1)
}
}
var r2 []byte
func BenchmarkCount2(b
The code: https://play.golang.org/p/DxUj6kBqf8k
The Filter4 function has one more assignment statement than Filter3.
But the benchmark result shows Filter4 is faster than Filter3.
The result:
cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
BenchmarkFilter3-43575656 980.2 ns/op
On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote:
> name time/op
> Filter3-4 1.38µs ± 0%
> Filter4-4 1.39µs ± 0%
>
>
What is your CPU model?
>
> On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> The code: h
4 tapi...@gmail.com wrote:
> On Friday, June 11, 2021 at 2:00:03 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Fri, Jun 11, 2021 at 9:38 AM tapi...@gmail.com
>> wrote:
>> >
>> > package allocate
>> >
>> > import "testing"
>> > impo
On Friday, June 11, 2021 at 2:00:03 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, Jun 11, 2021 at 9:38 AM tapi...@gmail.com
> wrote:
> >
> > package allocate
> >
> > import "testing"
> > import "os"
> > import "fmt"
On Saturday, June 12, 2021 at 12:04:21 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, Jun 11, 2021 at 11:21 PM tapi...@gmail.com
> wrote:
> >
> > It looks the _PageSize constant used in allocating large memory block is
> declared as 8192 in code, but os.Getpa
package main
import "testing"
var s33 = []byte{32: 'b'}
var a = string(s33)
func main() {
x := a + a // a + a does not escape
println(x)
}
func Benchmark_e_33(b *testing.B) {
var x string
for i := 0; i < b.N; i++ {
x = a + a // a + a escapes to heap
}
Is it possible that gc automatically replaces the "_" with a hidden
declared package-level variable?
On Wednesday, June 23, 2021 at 1:14:36 AM UTC-4 tapi...@gmail.com wrote:
> The code:
>
> package concat
>
> import (
> "testing"
> )
>
>
Is this to avoid stack growing to fast if there are some stack allocations
intervening with each other?
On Wednesday, June 23, 2021 at 12:39:17 AM UTC-4 tapi...@gmail.com wrote:
>
> package main
>
> import "testing"
>
> var s33 = []byte{32: 'b'}
>
> var a = str
The code:
package concat
import (
"testing"
)
var s33 = []byte{32: 'b'}
var a = string(s33)
func Benchmark_e_33(b *testing.B) {
for i := 0; i < b.N; i++ {
_ = a + a // a + a does not escape
}
}
"go test -gcflags=-m" shows: a + a does not escape
but "go test -bench=.
The benchmark code: https://play.golang.org/p/qp6wQgqcHKW
The result:
Benchmark_CompareWithSwitch0Bytes-4328873778 3.619
ns/op 0 B/op 0 allocs/op
Benchmark_CompareWithSwitch32Bytes-4 175067815 6.251
ns/op 0 B/op 0
Filled an issue: https://github.com/golang/go/issues/46908
On Thursday, June 24, 2021 at 10:50:31 PM UTC-4 tapi...@gmail.com wrote:
> Now, I think the escape analysis message should be "a + a does not
> escapes",
> which accurate meaning is "the header part
cape
> x = a + a // does not escape
> for i := 0; i < 1; i++ {
>
> x = a + a // a + a escapes to heap
> y := a + a // does not escape
> println(y)
> println(x)
> }
> }
>
>
> Only when a variable outside the loo
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.com/g
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) {
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
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
rtOneline-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
>>
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"
>>
>> con
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() {
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
>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(){
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
>&
elp?
>
>
> 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 another opti
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
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
, 2021 at 9:51:50 AM UTC-4 tapi...@gmail.com wrote:
>
> package main
>
> func newIntPtr(n int) *int {
> return
> }
>
> func main() {
> x := newIntPtr(3)
> y := newIntPtr(5)
> c := make(chan bool)
> go func() {
> *y++
> clo
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
ould 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
>>>>> not
>>>>> productiv
= 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 following program?
>
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 immedia
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
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 enough to handle many
>> cases.
>> But at this speci
re 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 maybe you should just try and
>>>
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
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 Sun, M
nstant. 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 time?
>&
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.
&g
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
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?
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
> wrote:
&g
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
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
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
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
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 this
>
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
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)
//
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
Another runnable example:
package main
const x = 8
var y = 8
var a byte = 1 << x / 2
var b byte = 1 << y / 2
func main() {
println(a) // 128
println(b) // 0
}
On Thursday, June 3, 2021 at 10:42:32 AM UTC-4 peterGo wrote:
> Jan,
>
> The untyped constant 1 assumes the type of x, which is
package main
func newIntPtr(n int) *int {
return
}
func main() {
x := newIntPtr(3)
y := newIntPtr(5)
c := make(chan bool)
go func() {
*y++
close(c)
}()
<-c
println(*x, *y)
println()
//println() // This line makes y escape.
}
--
You
021 at 10:26:04 AM UTC-4 Jan Mercl wrote:
> On Tue, Jun 1, 2021 at 3:52 PM tapi...@gmail.com
> wrote:
>
> By default, any local variable that has its address taken and that
> address can outlive the function execution forces the variable to
> escape, quite naturally as the st
at 4:25:18 AM UTC-4 tapi...@gmail.com wrote:
> I will if I get enough time and become more familiar with the code.
> Meanwhile, I think it is a not a bad idea to post my investigations here.
> If some people with relevant experiences could make some explanations
> without sp
On Tuesday, June 1, 2021 at 10:48:22 AM UTC-4 Jan Mercl wrote:
> On Tue, Jun 1, 2021 at 4:40 PM tapi...@gmail.com
> wrote:
>
> > The following is a tip to get an array pointer but avoid the array
> escaping.
>
> I don't think so. The pointer to the local array 't'
It is found that the test file is not written correctly.
The filtered data should be reset in each loop.
The corrected one: https://play.golang.org/p/yJMweZLIXAz
<https://t.co/dZUGrAQ1cB?amp=1>
;D
On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>
> The
For example, I don't want the time consumed for "copy(data2, data)" being
counted.
How to achieve this?
func BenchmarkFilter3(b *testing.B) {
data := buildOrginalData()
data2 := make([]int, len(data))
b.ResetTimer()
for i := 0; i < b.N; i++ {
copy(data2, data)
_
day, July 7, 2021 at 11:28:13 AM UTC-4 tapi...@gmail.com wrote:
>
> For example, I don't want the time consumed for "copy(data2, data)" being
> counted.
> How to achieve this?
>
> func BenchmarkFilter3(b *testing.B) {
> data := buildOrginalData()
&
er's solution exhausted my memory and hang my whole computer, and I have
to restart it.
>
> On Wednesday, July 7, 2021 at 11:29:30 AM UTC-4 tapi...@gmail.com wrote:
>
>> This doesn't work:
>>
>> func BenchmarkFilter3(b *testing.B) {
>> data := buildOrginalData()
>> data2
On Wednesday, July 7, 2021 at 8:01:54 PM UTC-4 tapi...@gmail.com wrote:
> On Wednesday, July 7, 2021 at 12:32:38 PM UTC-4 jake...@gmail.com wrote:
>
>> It would be helpful to give more information as to why you say "This
>> doesn't work"?
>> But, I'm guessing
side the loop is set inside the loop does it
> escape.
>
Yes, testing is not relevant here. It is the loop make effects here.
>
> On Wednesday, June 23, 2021 at 12:39:17 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> package main
>>
>> import "testing"
70>
>
> get run?" - is that right?
Almost true.
Whether or not it should run, growing the stack from 2048 to 512M in 18+
steps looks not right.
>
> On Wednesday, 30 June 2021 at 14:21:21 UTC+1 tapi...@gmail.com wrote:
>
>> Sorry, I post the wrong anchor. It is li
On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com
wrote:
> On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com
> wrote:
>
>>
>>
>> On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote:
>>
>>> So I think what y
It looks this line
https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never
gets executed.
An example:
package main
const N = 512 * 1024 * 1024 // 500M
var v byte = 123
func main() {
var s = []byte{N: 0}
for i := range s { s[i] = v }
println(s[v])
}
I added a
new goroutine still starts from 2048 bytes.
On Wednesday, June 30, 2021 at 3:25:59 AM UTC-4 tapi...@gmail.com wrote:
>
> It looks this line
> https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never
> gets executed.
>
> An example:
>
> package main
&g
e.
>
> V.
>
> On Thursday, 1 July 2021 at 03:03:37 UTC+2 tapi...@gmail.com wrote:
>
>> On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com
>> wrote:
>>
>>> On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com
>>> wrote:
>>&
ead.
With this change, the time needed to build the toolchain is reduced to
2m40.123s (from 3m3.897s).
On Thursday, July 1, 2021 at 8:42:41 AM UTC-4 Jan Mercl wrote:
> On Thu, Jul 1, 2021 at 2:34 PM tapi...@gmail.com
> wrote:
>
> > It is not rare a function will use 10M+ stack.
>
> What's
ncing a real problem due to this, you might
> want to open an issue.
>
> On Thu, Jul 1, 2021 at 3:04 AM tapi...@gmail.com
> wrote:
>
>>
>>
>> On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com
>> wrote:
>>
>>> On Thu, Ju
Sorry, I post the wrong anchor. It is line 1068:
https://github.com/golang/go/blob/d19a53338fa6272b4fe9c39d66812a79e1464cd2/src/runtime/stack.go#L1068
On Wednesday, June 30, 2021 at 5:08:30 AM UTC-4 Brian Candler wrote:
> On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wr
The code:
https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025
xxx > ir.MaxStackVarSize
xxx >= ir.MaxImplicitStackVarSize
This leads to the elements of a slice with size as ir.
MaxImplicitStackVarSize will be
Sorry, a typo in title. It should be "comparison".
On Saturday, June 26, 2021 at 5:50:55 AM UTC-4 tapi...@gmail.com wrote:
>
> The code:
> https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#
a bug. And if it's just curiosity, you can always try and
> change it and see what breaks. Go has a lot of tests.
>
> On Sat, Jun 26, 2021 at 11:52 AM tapi...@gmail.com
> wrote:
>
>> Sorry, a typo in title. It should be "comparison".
>>
>> On Saturday,
A some weak reason not to support the change.
Using unnamed parameter types could avoiding some explicit conversions.
package main
import "net/http"
type MyHandlerFunc func(http.ResponseWriter, *http.Request)
func f(http.HandlerFunc) {}
func g(MyHandlerFunc) {}
func
1 - 100 of 248 matches
Mail list logo
