[go-nuts] Re: Profiling goroutines

2021-09-03 Thread Alex Besogonov
Use pprof labels to mark goroutines. This provides way more context than anonymous goroutine IDs. On Friday, September 3, 2021 at 1:19:55 PM UTC-7 peppy...@gmail.com wrote: > Hey guys, > > I am trying to get a full picture using a pprof of a highly paralelised > binary (read many goroutines do

Re: [go-nuts] Profiling goroutines

2021-09-03 Thread Robert Engels
Check out github.com/robaho/go-analyzer. It has some nice enhancements for dealing with highly concurrent programs. > On Sep 3, 2021, at 3:20 PM, Peter Bočan wrote: > > Hey guys, > > I am trying to get a full picture using a pprof of a highly paralelised > binary (read many goroutines doi

[go-nuts] Profiling goroutines

2021-09-03 Thread Peter Bočan
Hey guys, I am trying to get a full picture using a pprof of a highly paralelised binary (read many goroutines doing stuff) but I am struggling to find any information on this topic - I think what I am seeing at the moment is just a single goroutine/main thread in the web UI that the tool prov

[go-nuts] Re: Questions about documentation of Go standard library

2021-09-03 Thread Kamil Ziemian
Hello, My struggles with regexp is going and I have another problem. I read closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax) and I still not sure if I understand one example from regexp package. In example in method func (*Regexp) FindIndex (https://pkg.go.dev/regexp@go1.

Re: [go-nuts] pkg.go.dev: navigation index is confusing

2021-09-03 Thread Markus Heukelom
> > @Markus: I normally use browser's search function to get to the function > and it works well with pkg.go.dev too. > > Using the search function only works if you know the name of the function. Very common examples when this doesn't work: Package HTTP: If you vaguely remember a function name,

[go-nuts] Re: I just published : Iterator lib for Go: Library providing Map(), Filter(), Reduce() for Go

2021-09-03 Thread Howard C. Shaw III
Just so you are aware of what's out there: https://github.com/robpike/filter "I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard. Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I

Re: [go-nuts] pkg.go.dev: navigation index is confusing

2021-09-03 Thread Wojciech S. Czarnecki
Dnia 2021-09-03, o godz. 12:26:39 Axel Wagner napisał(a): > And b) this is not a property of pkg.go.dev - the old godoc and godoc.org > both had the same behavior. > This also behaves the same. Look where StripPrefix is listed here: Hm... Yes. My bad, Axel. I should have checked before hitting

[go-nuts] Re: Why don't we have to use 'std' as the module prefix for packages from the standard library?

2021-09-03 Thread Volker Dobler
On Friday, 3 September 2021 at 02:18:54 UTC+2 Connor Kuehl wrote: > But this whole time as I've been learning the language, the standard > packages can be imported without any explicit prefix: > > import "fmt" > > and I found a go.mod in my Go distribution's standard library [1], so > that sug

[go-nuts] What is the recommended module-aware implementation of types.Importer?

2021-09-03 Thread sia...@gmail.com
Hi! I am trying to type check a Go module. The https://pkg.go.dev/go/types#Config's Importer field requires a https://pkg.go.dev/go/types#Importer. https://pkg.go.dev/go/importer#Default works well, however, it is not module-aware. Is golang.org/x/tools/go/packages the only way to load and typ

Re: [go-nuts] pkg.go.dev: navigation index is confusing

2021-09-03 Thread 'Axel Wagner' via golang-nuts
On Fri, Sep 3, 2021 at 12:22 PM Wojciech S. Czarnecki wrote: > Dnia 2021-09-02, o godz. 14:32:05 > "'Axel Wagner' via golang-nuts" napisał(a): > > > On Thu, Sep 2, 2021 at 12:26 PM Markus Heukelom < > markus.heuke...@gain.pro> > > wrote: > > > > > So, turns out, the function is actually listed u

Re: [go-nuts] pkg.go.dev: navigation index is confusing

2021-09-03 Thread Wojciech S. Czarnecki
Dnia 2021-09-02, o godz. 14:32:05 "'Axel Wagner' via golang-nuts" napisał(a): > On Thu, Sep 2, 2021 at 12:26 PM Markus Heukelom > wrote: > > > So, turns out, the function is actually listed under the type "Handler", > > probably because it implements that interface. > > > > It's a heuristic

Re: [go-nuts] Re: WASM Performance

2021-09-03 Thread Stephen Illingworth
To follow up on this I should clarify what my questions are: 1) How much of a performance drop (when compared to AMD64 for example) should I expect when compiling to the WASM target? 2) Is there anything obvious I can do to counter any performance drops? And I suppose this is a non-Go question,

Re: [go-nuts] Re: WASM Performance

2021-09-03 Thread Stephen Illingworth
On Fri, Sep 3, 2021 at 10:15 AM Brian Candler wrote: > Could you explain a bit more about what you're comparing? > > - Is the wasm version running in a browser? If so, which one? Or have you > got a way to run wasm directly on the host (in which case, what is it)? > Running it in Firefox (78.13.

[go-nuts] Re: WASM Performance

2021-09-03 Thread Brian Candler
Could you explain a bit more about what you're comparing? - Is the wasm version running in a browser? If so, which one? Or have you got a way to run wasm directly on the host (in which case, what is it)? - How is the linux/amd64 version running, if it's not talking to a DOM-type environment? If

[go-nuts] WASM Performance

2021-09-03 Thread stephen.t....@gmail.com
Hello, I have a moderately large Go project that performs fine on my development machine. However when compiled for WASM the performance drops off significantly. I'm hoping someone can help me understand why. For comparison purposes, on my hardware, the emulator will run uncapped at a 110-120f