There was a lot of discussion of this on the proposal, starting with (and
well summarized by) https://go.dev/issue/61515#issuecomment-1646194700. If
we don't inline, there will be cases like yours that wanted to benchmark
with inlining but don't get it. If we do inline, there will be cases that
are
Could you file an issue about this with reproduction steps? My attempt to
reproduce this works fine.
go.mod
```
module example.com
go 1.24rc1
tool (
golang.org/x/tools/cmd/stringer
golang.org/x/tools/cmd/toolstash
)
require (
golang.org/x/mod v0.22.0 // indirect
Thanks for the report. Normally, https://go.dev/issue/46477 redirects to
https://github.com/golang/go/issues/46477. That redirect doesn't work on
tip.golang.org, tracked by https://go.dev/issue/58484. Russ just mailed
https://go.dev/cl/634915, which should fix this when it rolls out.
On Tue, Dec 1
You can just set the environment variable, so `GOEXPERIMENT=swissmap go
test`.
On Fri, Aug 16, 2024 at 3:28 PM Leah Stapleton
wrote:
> Hi,
> I have a question about building go source code to run the tests go swiss
> maps experiments.
>
> first off,
> There are tests with the same name in map_sw
Hi Adam,
Thanks for sending this, lots of interesting ideas here!
I've been meaning for a long time to have more concrete guidelines for how
much data collection is enough for good results, to include on
https://go.dev/doc/pgo.
I also think it would be valuable to provide tooling that can help m
Setting GODEBUG=inittrace=1 will log a trace of init function execution,
which you can use to determine if init is slow, and if so which packages.
e.g., `GODEBUG=inittrace=1 go version` ends with "init main @9.5 ms",
indicating that it look 9.5ms to run all init functions.
The format is described
I can reproduce similar behavior on linux-amd64:
$ perf stat ./example.com.test -test.bench=BenchmarkInline
-test.benchtime=1x
goos: linux
goarch: amd64
pkg: example.com
cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz
BenchmarkInline-12 1 16.78 ns/op
PASS
Performan
This sounds like https://go.dev/issue/48956. In that case, it was some
interference from an extension.
On Tue, Apr 26, 2022 at 4:55 PM Ian Lance Taylor wrote:
> On Tue, Apr 26, 2022 at 12:40 AM christoph...@gmail.com
> wrote:
> >
> > This is a screen capture of what I see https://imgur.com/a/nu
Go has a non-moving GC [1], so that is not an issue. That said,
unsafe.Pointer states "the referenced allocated object, if any, is retained
and not moved until the call completes". It doesn't say that this
recursively applies to objects referenced by the converted object, though I
perhaps it should
You can use a *byte for the buffer. For instance, unix.Iovec does this:
https://pkg.go.dev/golang.org/x/sys/unix#Iovec
Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall without
any special handling of the *byte field.
On Fri, May 14, 2021, 09:01 sh...@tigera.io wrote:
> Now, i
Oops, I should say the syscall package could do this. x/sys/unix has the
extra complexity of not being tied to a Go release.
On Tue, Apr 27, 2021, 12:53 Michael Pratt wrote:
> I'm not sure if calling through the VDSO is the best solution to this
> specific issue, though it does sound like a case
I'm not sure if calling through the VDSO is the best solution to this
specific issue, though it does sound like a case that would certainly
benefit.
Regardless, one fairly clean way we could support this would be to make
x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
than
mgcsweepbuf.go was deleted in 1.16, so it seems you still have files from
1.15 sitting around in /usr/local/go/.
On Fri, Apr 2, 2021 at 4:13 AM Jan Mercl <0xj...@gmail.com> wrote:
> On Thu, Apr 1, 2021 at 11:52 PM Dmitri Shuralyov
> wrote:
>
> > We have just released Go versions 1.16.3 and 1.15.
13 matches
Mail list logo
