Re: [go-nuts] Re: Speed up png.Decode

Thanks Rob, Yes you are right these images are small. <100kb each with an example below. And as I mentioned I have millions of these. I am able to max the CPUs out with a worker pool but that is when I noticed a lot of the work was actually decoding the PNG images which made we wonder if if was

Re: [go-nuts] Re: [generics] default type parameter

Yes I did. Sorry all. > On Jun 26, 2020, at 7:42 PM, Sebastien Rosset wrote: > >  > Did you reply to the wrong thread? > >> On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote: >> What about an option to disable the signal on the thread as it crosses the >> CGo boundary? This

Re: [go-nuts] Re: [generics] default type parameter

Did you reply to the wrong thread? On Friday, June 26, 2020 at 3:09:42 PM UTC-7, Robert Engels wrote: > > What about an option to disable the signal on the thread as it crosses the > CGo boundary? This seems better than disabling the async preemption > entirely? > > On Jun 26, 2020, at 4:45 PM,

Re: [go-nuts] Re: Speed up png.Decode

Without information about the particular images - the data set you're working with - it's hard to provide any accurate advice. If the images are small, maybe it's all overhead. If the images are of a particular form of PNG, maybe a fast path is missing. And so on. To get meaningful help for

Re: [go-nuts] Slices and inconsistency

On Jun 26, 2020, at 2:59 PM, Ian Lance Taylor wrote: > > I honestly don't think that append is an example of worse-is-better. > I think it's an example of preferring to pass and return values rather > than pointers. The language could easily have made append take a > pointer to a slice as its

Re: [go-nuts] Slices and inconsistency

> On Jun 26, 2020, at 2:52 PM, Tyler Compton wrote: > > On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: >> Also, to this specific point: this exact approach, as with much of Go, >> embodies the Bell Labs approach to design (for better or for worse, and with >> good reason). Sometimes

Re: [go-nuts] Re: [generics] default type parameter

What about an option to disable the signal on the thread as it crosses the CGo boundary? This seems better than disabling the async preemption entirely? > On Jun 26, 2020, at 4:45 PM, Sebastien Rosset wrote: > >  > > Below are the publicly exposed asn1.ObjectIdentifier fields in the

Re: [go-nuts] Re: [generics] default type parameter

Below are the publicly exposed asn1.ObjectIdentifier fields in the golang/go repo. It has fairly limited exposure, but I'm sure some people will argue it's too much (maybe ok in go 2.x but not 1.x?). 1. encoding/asn1: 1. My guess is this would be primarily used by SNMP applications

Re: [go-nuts] Re: [generics] default type parameter

On Fri, Jun 26, 2020 at 12:54 PM Sebastien Rosset wrote: > > As an aside, the most common use of the encoding/asn1 package is most likely > crypto/x509. x509. Certificate exposes public fields that use the > asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of > applications, such

[go-nuts] Re: go.pkg.dev: blitznote.com/src/semver doesn't show up

For me it is in the search results. Currently on page 5, fifth entry: https://pkg.go.dev/search?page=5=semver On Friday, 26 June 2020 at 21:47:30 UTC+2 Mark Kubacki wrote: > Hi, > > I've noticed my package, blitznote.com/src/semver, doesn't show up in > pkg.go.dev despite having been licensed

Re: [go-nuts] Re: [generics] default type parameter

As an aside, the most common use of the encoding/asn1 package is most likely crypto/x509. x509. Certificate exposes public fields that use the asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of applications, such as for TLS connection management. On Friday, June 26, 2020 at

[go-nuts] go.pkg.dev: blitznote.com/src/semver doesn't show up

Hi, I've noticed my package, blitznote.com/src/semver, doesn't show up in pkg.go.dev despite having been licensed under one of the blessed licenses, being some months old, and having been pulled several times using the default proxy. Specifically, searching for “semver” won't produce it, even

Re: [go-nuts] Re: [generics] default type parameter

sure, thank you. I will go through the PR review process for asn1 and x509, maybe some good ideas will come up. Sebastien On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote: > > On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset > wrote: > > > > @ianlancetaylor , thank you

Re: [go-nuts] Slices and inconsistency

On Fri, Jun 26, 2020 at 11:52 AM Tyler Compton wrote: > > On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: >> >> Also, to this specific point: this exact approach, as with much of Go, >> embodies the Bell Labs approach to design (for better or for worse, and with >> good reason). Sometimes

Re: [go-nuts] How to do "frame" based profiling in GO?

Hi, thanks for the quick reply. I tried that but I fear I don't really understand the API/tools for that. What I did was wrapping the update function called every frame like that: func profUpdate(update func(time.Duration), frame *uint64) func(time.Duration) { return func(time.Duration) {

Re: [go-nuts] Slices and inconsistency

On Fri, Jun 26, 2020 at 10:52 AM David Riley wrote: > Also, to this specific point: this exact approach, as with much of Go, > embodies the Bell Labs approach to design (for better or for worse, and > with good reason). Sometimes we have to live with the artifacts of > evolution. > One

Re: [go-nuts] Re: [generics] default type parameter

On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset wrote: > > @ianlancetaylor , thank you for the quick reply. The reason I was asking is > because potentially this could have been used to fix `type ObjectIdentifier > []int` in the `encoding/asn1` package and the `crypto/x509` package. >

Re: [go-nuts] How to do "frame" based profiling in GO?

You want to use pprof “labels” and mark the frames. > On Jun 26, 2020, at 1:35 PM, michael.nis...@gmail.com wrote: > >  > Hello, > > I'm trying to figure out how to do "frame" based profiling in GO and was > redirect to this mailing--list from the `r/golang` sub (topic). Would be > amazing

[go-nuts] How to do "frame" based profiling in GO?

Hello, I'm trying to figure out how to do "frame" based profiling in GO and was redirect to this mailing--list from the `r/golang` sub (topic ). Would be amazing if anyone here can help. In short: I

[go-nuts] Re: [generics] default type parameter

@ianlancetaylor , thank you for the quick reply. The reason I was asking is because potentially this could have been used to fix `type ObjectIdentifier []int` in the `encoding/asn1` package and the `crypto/x509` package. Currently these package are not fully compliant with the ASN.1

[go-nuts] [generics] default type parameter

First apologies for initially bringing up the topic as a github issue rather than golang-nuts. I am copy-pasting my question here with @ianlancetaylor response. A default type value can be specified in C++ templates. I was asking if a similar construct been considered for go generic type

Re: [go-nuts] Slices and inconsistency

On Jun 26, 2020, at 1:41 PM, Robert Engels wrote: > > My opinion is that if RTFM is required more than once for a core concept > there may be a design problem. It clearly bites a lot of people. Slices are a > higher level struct, as the underlying array is the same as Java, but Java > doesn’t

Re: [go-nuts] Slices and inconsistency

On Jun 26, 2020, at 1:41 PM, Robert Engels wrote: > > I don’t think “how it works” is the confusion, more of “how to use it > properly” > > My opinion is that if RTFM is required more than once for a core concept > there may be a design problem. It clearly bites a lot of people. Slices are a

Re: [go-nuts] Slices and inconsistency

I don’t think “how it works” is the confusion, more of “how to use it properly” My opinion is that if RTFM is required more than once for a core concept there may be a design problem. It clearly bites a lot of people. Slices are a higher level struct, as the underlying array is the same as

Re: [go-nuts] Slices and inconsistency

"If the capacity of s is not large enough to fit the additional values, append allocates a new, sufficiently large underlying array that fits both the existing slice elements and the additional values. Otherwise, append re-uses the underlying array." That seems pretty explicit to me? That's

Re: [go-nuts] Re: accessibility of module version information in executable

* seank...@gmail.com [200626 12:31]: > go version -m $binary > > runtime/debug.BuildInfo Thanks much! I looked through runtime, but did not think to look at runtime/debug. I was completely unaware of the -m option to go version. ...Marvin -- You received this message because you are

[go-nuts] Re: accessibility of module version information in executable

go version -m $binary runtime/debug.BuildInfo On Friday, June 26, 2020 at 6:13:56 PM UTC+2 Marvin Renich wrote: > When building a command with go build that imports modules, does the > resulting executable contain information about which modules are > included as well as their versions? > > If

[go-nuts] accessibility of module version information in executable

When building a command with go build that imports modules, does the resulting executable contain information about which modules are included as well as their versions? If so, is there a tool available to extract that information from the executable? Can the information be retrieved from within

Re: [go-nuts] Slices and inconsistency

> On Jun 26, 2020, at 9:28 AM, Robert Engels wrote: > >> On Jun 26, 2020, at 8:23 AM, David Riley wrote: >> >> You are correct, the programmer needs to read the manual. Slices are >> "windows" into their underlying array, therefore assigning data into slices >> tied to a given array changes

Re: [go-nuts] Slices and inconsistency

That is not quite true. Once is it extended beyond the current capacity you will have a new backing array and the slices will diverge. > On Jun 26, 2020, at 8:23 AM, David Riley wrote: > > On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote: >> >> Essentially based on the existing

Re: [go-nuts] Slices and inconsistency

On Jun 25, 2020, at 8:49 PM, chandrak13...@gmail.com wrote: > > Essentially based on the existing capacity, the assignment of one slice > effects other slices. These are stemming from the underlying pointer > arithmetic and seems inconsistent. Looks like programmer needs to know the > history

Re: [go-nuts] Re: Speed up png.Decode

Thanks, I am already maxing out some servers but wondered if it could be sped up. I will give the bimg package a go! On Friday, June 26, 2020 at 1:55:40 PM UTC+1 ren...@ix.netcom.com wrote: > Just parallelize in the cloud. At a minimum parallelize locally with > multiple Go routines. > > On

Re: [go-nuts] Re: Speed up png.Decode

Just parallelize in the cloud. At a minimum parallelize locally with multiple Go routines. > On Jun 26, 2020, at 7:51 AM, howardcs...@gmail.com wrote: > >  > I don't know if the CGo transitions for 16 million images will completely > swamp the speed gains, or how much post-processing you

[go-nuts] Re: Speed up png.Decode

I don't know if the CGo transitions for 16 million images will completely swamp the speed gains, or how much post-processing you need to do to these images, but you might try https://github.com/h2non/bimg and see if it gives you any wins. It claims 'typically 4x faster' then the Go Image