Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Ian Lance Taylor 
On Sat, Oct 19, 2019 at 10:17 PM Nidhi Agrawal  wrote:
>
>
> https://golang.org/src/runtime/mprof.go, 
> https://golang.org/pkg/net/http/pprof/ here it is mentioned that we need to 
> set SetBlockProfileRate to get enable block profile.
>
> In case of block profiling if I set rate just before profiling and reset it 
> to 0 after profiling i am not getting any data.
>
> I am doing something like:
> SetBlockProfileRate(1)
> pprof.Lookup("block").WriteTo(f, 0);
> SetBlockProfileRate(0)

If that is exactly what you are doing, then that doesn't work for CPU
profiling either.  You need to call SetBlockProfileRate, then do some
work, then fetch the profile.

Ian


> On Sun, Oct 20, 2019 at 10:24 AM Ian Lance Taylor  wrote:
>>
>> On Sat, Oct 19, 2019 at 7:34 PM Nidhi Agrawal  wrote:
>> >
>> > We don't need to set MemProfileRate. It is about block and mutex profiling 
>> > where we need to set the rate (SetBlockProfileRate, 
>> > SetMutexProfileFraction) at application start. Is there any performance 
>> > impacts of doing that ?
>> >
>> > It is not causing any issue we want to enable block and mutex profiling so 
>> > i am thinking if we can do something like
>> >   SetBlockProfileRate(1)
>> >   pprof.Lookup("block").WriteTo(f, 0);
>> >   sleep(20)
>> >   SetBlockProfileRate(0)
>> > just like how cpu and trace profile works. But i am curious why isn't it 
>> > not already done in the library. What can be the reason behind this?
>> >
>> > I am curious why they are different from cpu and trace profiling, trying 
>> > to understand the inner working of this. It would be really helpful if you 
>> > can give me some pointers on where i can read about the high level design 
>> > of the pprof.
>>
>> Oh, sorry, I misread what you were asking.  But now I'm not sure what
>> you are asking.  You said
>>
>> > On the other hand for mutex and block profiling, it expects us to set the 
>> > rate at the start of the application and while calling profiling, it just 
>> > gathers the information and return.
>>
>> That's how memory profiling works.  You don't have to set the mutex
>> and profiling rates at the start of the application.  You can set them
>> when you want to start profiling, as you suggest.  Is there some
>> documentation that says otherwise?
>>
>> Sorry, I don't know of any documentation describing the profiling
>> implementation.
>>
>> Ian

-- 
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/msgid/golang-nuts/CAOyqgcXPEK3TKqs-QiLQOxtdUGQO6nyzDDkODyDEWqN0C%3Df99w%40mail.gmail.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Nidhi Agrawal 
Ok, Is it necessary to call SetBlockProfileRate at the start of application?
If not then we can call it just before starting block profile and after
block profile interval (eg. 30 seconds) when profiling finishes then we can
reset it to 0.

On Sun, Oct 20, 2019 at 12:48 PM Ian Lance Taylor  wrote:

> On Sat, Oct 19, 2019 at 10:17 PM Nidhi Agrawal 
> wrote:
> >
> >
> > https://golang.org/src/runtime/mprof.go,
> https://golang.org/pkg/net/http/pprof/ here it is mentioned that we need
> to set SetBlockProfileRate to get enable block profile.
> >
> > In case of block profiling if I set rate just before profiling and reset
> it to 0 after profiling i am not getting any data.
> >
> > I am doing something like:
> > SetBlockProfileRate(1)
> > pprof.Lookup("block").WriteTo(f, 0);
> > SetBlockProfileRate(0)
>
> If that is exactly what you are doing, then that doesn't work for CPU
> profiling either.  You need to call SetBlockProfileRate, then do some
> work, then fetch the profile.
>
> Ian
>
>
> > On Sun, Oct 20, 2019 at 10:24 AM Ian Lance Taylor 
> wrote:
> >>
> >> On Sat, Oct 19, 2019 at 7:34 PM Nidhi Agrawal 
> wrote:
> >> >
> >> > We don't need to set MemProfileRate. It is about block and mutex
> profiling where we need to set the rate (SetBlockProfileRate,
> SetMutexProfileFraction) at application start. Is there any performance
> impacts of doing that ?
> >> >
> >> > It is not causing any issue we want to enable block and mutex
> profiling so i am thinking if we can do something like
> >> >   SetBlockProfileRate(1)
> >> >   pprof.Lookup("block").WriteTo(f, 0);
> >> >   sleep(20)
> >> >   SetBlockProfileRate(0)
> >> > just like how cpu and trace profile works. But i am curious why isn't
> it not already done in the library. What can be the reason behind this?
> >> >
> >> > I am curious why they are different from cpu and trace profiling,
> trying to understand the inner working of this. It would be really helpful
> if you can give me some pointers on where i can read about the high level
> design of the pprof.
> >>
> >> Oh, sorry, I misread what you were asking.  But now I'm not sure what
> >> you are asking.  You said
> >>
> >> > On the other hand for mutex and block profiling, it expects us to set
> the rate at the start of the application and while calling profiling, it
> just gathers the information and return.
> >>
> >> That's how memory profiling works.  You don't have to set the mutex
> >> and profiling rates at the start of the application.  You can set them
> >> when you want to start profiling, as you suggest.  Is there some
> >> documentation that says otherwise?
> >>
> >> Sorry, I don't know of any documentation describing the profiling
> >> implementation.
> >>
> >> Ian
>

-- 
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/msgid/golang-nuts/CACcVEiUKj8hdZm4%2BFv4QDD0HyjA%3D-wWrQZEV1L2u%3Dt5cijv-2Q%40mail.gmail.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Ian Lance Taylor 
On Sun, Oct 20, 2019 at 12:23 AM Nidhi Agrawal  wrote:
>
> Ok, Is it necessary to call SetBlockProfileRate at the start of application?
> If not then we can call it just before starting block profile and after block 
> profile interval (eg. 30 seconds) when profiling finishes then we can reset 
> it to 0.

As far as I know you can call SetBlockProfileRate at any time.

Why do you think that it must be called at the start of the application?

Ian


> On Sun, Oct 20, 2019 at 12:48 PM Ian Lance Taylor  wrote:
>>
>> On Sat, Oct 19, 2019 at 10:17 PM Nidhi Agrawal  wrote:
>> >
>> >
>> > https://golang.org/src/runtime/mprof.go, 
>> > https://golang.org/pkg/net/http/pprof/ here it is mentioned that we need 
>> > to set SetBlockProfileRate to get enable block profile.
>> >
>> > In case of block profiling if I set rate just before profiling and reset 
>> > it to 0 after profiling i am not getting any data.
>> >
>> > I am doing something like:
>> > SetBlockProfileRate(1)
>> > pprof.Lookup("block").WriteTo(f, 0);
>> > SetBlockProfileRate(0)
>>
>> If that is exactly what you are doing, then that doesn't work for CPU
>> profiling either.  You need to call SetBlockProfileRate, then do some
>> work, then fetch the profile.
>>
>> Ian
>>
>>
>> > On Sun, Oct 20, 2019 at 10:24 AM Ian Lance Taylor  wrote:
>> >>
>> >> On Sat, Oct 19, 2019 at 7:34 PM Nidhi Agrawal  
>> >> wrote:
>> >> >
>> >> > We don't need to set MemProfileRate. It is about block and mutex 
>> >> > profiling where we need to set the rate (SetBlockProfileRate, 
>> >> > SetMutexProfileFraction) at application start. Is there any performance 
>> >> > impacts of doing that ?
>> >> >
>> >> > It is not causing any issue we want to enable block and mutex profiling 
>> >> > so i am thinking if we can do something like
>> >> >   SetBlockProfileRate(1)
>> >> >   pprof.Lookup("block").WriteTo(f, 0);
>> >> >   sleep(20)
>> >> >   SetBlockProfileRate(0)
>> >> > just like how cpu and trace profile works. But i am curious why isn't 
>> >> > it not already done in the library. What can be the reason behind this?
>> >> >
>> >> > I am curious why they are different from cpu and trace profiling, 
>> >> > trying to understand the inner working of this. It would be really 
>> >> > helpful if you can give me some pointers on where i can read about the 
>> >> > high level design of the pprof.
>> >>
>> >> Oh, sorry, I misread what you were asking.  But now I'm not sure what
>> >> you are asking.  You said
>> >>
>> >> > On the other hand for mutex and block profiling, it expects us to set 
>> >> > the rate at the start of the application and while calling profiling, 
>> >> > it just gathers the information and return.
>> >>
>> >> That's how memory profiling works.  You don't have to set the mutex
>> >> and profiling rates at the start of the application.  You can set them
>> >> when you want to start profiling, as you suggest.  Is there some
>> >> documentation that says otherwise?
>> >>
>> >> Sorry, I don't know of any documentation describing the profiling
>> >> implementation.
>> >>
>> >> Ian

-- 
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/msgid/golang-nuts/CAOyqgcUpViwb0zzCR%3DBRWJ-GpqYdiaOeGCwHY_McODyEUcCvAQ%40mail.gmail.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Nidhi Agrawal 
Because it is explicitly written in the documentation here
https://golang.org/pkg/net/http/pprof/ that we should set block profile
rate at the start of application, unlike CPU profiling where the rate is
being set internally before profiling starts.

As you said we can set the rate any time then similar to cpu profiling,
block/mutex profiling can also be implemented like
go tool pprof http://localhost:6060/debug/pprof/block?seconds=30&rate=1
Where internally we set the rate before profiling starts.

I wanted to understand if there is any reason for such different
implementation.

On Sun, Oct 20, 2019 at 12:58 PM Ian Lance Taylor  wrote:

> On Sun, Oct 20, 2019 at 12:23 AM Nidhi Agrawal 
> wrote:
> >
> > Ok, Is it necessary to call SetBlockProfileRate at the start of
> application?
> > If not then we can call it just before starting block profile and after
> block profile interval (eg. 30 seconds) when profiling finishes then we can
> reset it to 0.
>
> As far as I know you can call SetBlockProfileRate at any time.
>
> Why do you think that it must be called at the start of the application?
>
> Ian
>
>
> > On Sun, Oct 20, 2019 at 12:48 PM Ian Lance Taylor 
> wrote:
> >>
> >> On Sat, Oct 19, 2019 at 10:17 PM Nidhi Agrawal 
> wrote:
> >> >
> >> >
> >> > https://golang.org/src/runtime/mprof.go,
> https://golang.org/pkg/net/http/pprof/ here it is mentioned that we need
> to set SetBlockProfileRate to get enable block profile.
> >> >
> >> > In case of block profiling if I set rate just before profiling and
> reset it to 0 after profiling i am not getting any data.
> >> >
> >> > I am doing something like:
> >> > SetBlockProfileRate(1)
> >> > pprof.Lookup("block").WriteTo(f, 0);
> >> > SetBlockProfileRate(0)
> >>
> >> If that is exactly what you are doing, then that doesn't work for CPU
> >> profiling either.  You need to call SetBlockProfileRate, then do some
> >> work, then fetch the profile.
> >>
> >> Ian
> >>
> >>
> >> > On Sun, Oct 20, 2019 at 10:24 AM Ian Lance Taylor 
> wrote:
> >> >>
> >> >> On Sat, Oct 19, 2019 at 7:34 PM Nidhi Agrawal 
> wrote:
> >> >> >
> >> >> > We don't need to set MemProfileRate. It is about block and mutex
> profiling where we need to set the rate (SetBlockProfileRate,
> SetMutexProfileFraction) at application start. Is there any performance
> impacts of doing that ?
> >> >> >
> >> >> > It is not causing any issue we want to enable block and mutex
> profiling so i am thinking if we can do something like
> >> >> >   SetBlockProfileRate(1)
> >> >> >   pprof.Lookup("block").WriteTo(f, 0);
> >> >> >   sleep(20)
> >> >> >   SetBlockProfileRate(0)
> >> >> > just like how cpu and trace profile works. But i am curious why
> isn't it not already done in the library. What can be the reason behind
> this?
> >> >> >
> >> >> > I am curious why they are different from cpu and trace profiling,
> trying to understand the inner working of this. It would be really helpful
> if you can give me some pointers on where i can read about the high level
> design of the pprof.
> >> >>
> >> >> Oh, sorry, I misread what you were asking.  But now I'm not sure what
> >> >> you are asking.  You said
> >> >>
> >> >> > On the other hand for mutex and block profiling, it expects us to
> set the rate at the start of the application and while calling profiling,
> it just gathers the information and return.
> >> >>
> >> >> That's how memory profiling works.  You don't have to set the mutex
> >> >> and profiling rates at the start of the application.  You can set
> them
> >> >> when you want to start profiling, as you suggest.  Is there some
> >> >> documentation that says otherwise?
> >> >>
> >> >> Sorry, I don't know of any documentation describing the profiling
> >> >> implementation.
> >> >>
> >> >> Ian
>

-- 
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/msgid/golang-nuts/CACcVEiUeadG8zgO42oQNQn%3DxKO0DGC00MnRS%2B0%2B%3DYsOB%3DKCyig%40mail.gmail.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Ian Lance Taylor 
On Sun, Oct 20, 2019 at 12:36 AM Nidhi Agrawal  wrote:
>
> Because it is explicitly written in the documentation here 
> https://golang.org/pkg/net/http/pprof/ that we should set block profile rate 
> at the start of application, unlike CPU profiling where the rate is being set 
> internally before profiling starts.

I'm likely missing something, but I'm looking at
https://golang.org/pkg/net/http/pprof, and I don't see that.  I see
that it says that you have to call runtime.SetBlockProfileRate or
runtime.SetMutexProfileFraction, but I don't see anything that says
that you have to call it at the start of the application.

Ian

-- 
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/msgid/golang-nuts/CAOyqgcXuT250uGx7auLwjAqUHMm5%3DLvkwLy5oHanx2oq9XxwqA%40mail.gmail.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Nidhi Agrawal 
I came to this conclusion because the pprof implemented the cpu with the
assumption that the client gives how much time to capture the profiling
data. but when it comes to the mutex and block, the pprof didn't implement
it to support this but asked the client to call the profile rate before
calling the pprof function. This made me question why is there a difference
in the profiling technique, is it expected from us to set profile rate at
the start of the program, if not then why didn't they implement it similar
to the cpu.

On Sun, Oct 20, 2019 at 1:10 PM Ian Lance Taylor  wrote:

> On Sun, Oct 20, 2019 at 12:36 AM Nidhi Agrawal 
> wrote:
> >
> > Because it is explicitly written in the documentation here
> https://golang.org/pkg/net/http/pprof/ that we should set block profile
> rate at the start of application, unlike CPU profiling where the rate is
> being set internally before profiling starts.
>
> I'm likely missing something, but I'm looking at
> https://golang.org/pkg/net/http/pprof, and I don't see that.  I see
> that it says that you have to call runtime.SetBlockProfileRate or
> runtime.SetMutexProfileFraction, but I don't see anything that says
> that you have to call it at the start of the application.
>
> Ian
>

-- 
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/msgid/golang-nuts/CACcVEiXvH3KnxaaonOkNmh1VsdQB7LbWKxFc25vvfFVw8nx2BQ%40mail.gmail.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Ian Lance Taylor 
On Sun, Oct 20, 2019 at 12:51 AM Nidhi Agrawal  wrote:
>
> I came to this conclusion because the pprof implemented the cpu with the 
> assumption that the client gives how much time to capture the profiling data. 
> but when it comes to the mutex and block, the pprof didn't implement it to 
> support this but asked the client to call the profile rate before calling the 
> pprof function. This made me question why is there a difference in the 
> profiling technique, is it expected from us to set profile rate at the start 
> of the program, if not then why didn't they implement it similar to the cpu.

I'm sorry, I don't really understand what you mean.

There is really no difference among CPU, block, and mutex profiling
with regard to how they are used.  In all cases you start profiling,
do some work, and then fetch the profile.  They are all more or less
the same.  I don't understand what is leading you to conclude that
they are different.

Heap profiling, on the other hand, really is different, and it is
documented differently in runtime/pprof.

Ian


> On Sun, Oct 20, 2019 at 1:10 PM Ian Lance Taylor  wrote:
>>
>> On Sun, Oct 20, 2019 at 12:36 AM Nidhi Agrawal  wrote:
>> >
>> > Because it is explicitly written in the documentation here 
>> > https://golang.org/pkg/net/http/pprof/ that we should set block profile 
>> > rate at the start of application, unlike CPU profiling where the rate is 
>> > being set internally before profiling starts.
>>
>> I'm likely missing something, but I'm looking at
>> https://golang.org/pkg/net/http/pprof, and I don't see that.  I see
>> that it says that you have to call runtime.SetBlockProfileRate or
>> runtime.SetMutexProfileFraction, but I don't see anything that says
>> that you have to call it at the start of the application.
>>
>> Ian

-- 
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/msgid/golang-nuts/CAOyqgcXMkT_aOtkCd4QTAi1E2-cOcwTNLtQ85iteJJte6sURMA%40mail.gmail.com.

[go-nuts] golang to fpga compilation

2019-10-20 Thread Wang Sheng 
xilinx release   fpga production for cloude service now , if golang can be 
compiled to fpga ,   that would be a su exciting  future . 

Does anyoneo have any suggestions  for development of compilation for 
golang to fpga ?

-- 
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/msgid/golang-nuts/b5dd15f6-03ac-4c8e-a54c-8aab104a3368%40googlegroups.com.

[go-nuts] [ANN] fxamacker/cbor v1.0 and v1.1 ( CBOR library in Go)

2019-10-20 Thread Faye Amacker 
CBOR is a concise binary alternative to JSON, and is specified in RFC 7049.

fxamacker/cbor  is a CBOR library that 
is:

   - *Easy* -- idiomatic API like Go's encoding/json.
   - *Safe and reliable* -- avoids Go's unsafe, has 95+% coverage, and 
   passes 10+ hrs of fuzzing before each release.
   - *Standards-compliant* -- supports CBOR, including canonical CBOR 
   encodings (RFC 7049 and CTAP2).
   - *Small and self-contained* -- compiles to under 0.5 MB and has no 
   external dependencies.

Version 1.x has:

   - *Stable API* -- won't make breaking API changes.
   - *Stable requirements* -- won't require Go newer than v1.12.
   - *No known bugs* -- no open issues to fix bugs.
   - *Passed 30+ hrs of fuzzing* -- v1.1.1 on linux_amd64 using prior 
   corpus and RFC 7049 tests as seed.


This library balances speed, safety, and compiled size. To keep size small, 
it avoids code generation. For safety, it avoids Go's unsafe. For speed, it 
uses safe optimizations: cache struct metadata, bypass reflect when 
appropriate, use sync.Pool to reuse transient objects, and etc.

Program size comparisons (doing the same CBOR encoding and decoding):

   - 2.7 MB program using fxamacker/cbor v1.1.1
   - 10.7 MB program using ugorji/go v1.1.7 (without code generation)
   - 11.9 MB program using ugorji/go v1.1.7 (default build)


Changes to fxamacker/cbor since pre-1.0 announcement include:

   - v1.1.1 -- improve encoding speeds: slice 50%, struct 30%, and map 14%
   - v1.1.0 -- support encoding.BinaryMarshaler and 
   encoding.BinaryUnmarshaler interfaces
   - v1.0.x -- refactoring and cleanup


I'd love to know if you use this library, so please let me know (include 
your project link if possible).

Questions and suggestions are welcome.

-- 
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/msgid/golang-nuts/d896ca2f-1a8d-4bb3-a01d-e775a1b1342e%40googlegroups.com.

Re: [go-nuts] Doubts regarding implementation of runtime profiler

2019-10-20 Thread Nidhi Agrawal 
Implementation in http/net/pprof library is leading me to conclude that
they are different.
Yes, In runtime/pprof block, mutex, cpu all are implemented in the same
way, but http/net/pprof is not using them in the same way.
In CPU profiling rate is set internally, while in block, mutex we are
supposed to set the rate.

On Sun, Oct 20, 2019 at 1:27 PM Ian Lance Taylor  wrote:

> On Sun, Oct 20, 2019 at 12:51 AM Nidhi Agrawal 
> wrote:
> >
> > I came to this conclusion because the pprof implemented the cpu with the
> assumption that the client gives how much time to capture the profiling
> data. but when it comes to the mutex and block, the pprof didn't implement
> it to support this but asked the client to call the profile rate before
> calling the pprof function. This made me question why is there a difference
> in the profiling technique, is it expected from us to set profile rate at
> the start of the program, if not then why didn't they implement it similar
> to the cpu.
>
> I'm sorry, I don't really understand what you mean.
>
> There is really no difference among CPU, block, and mutex profiling
> with regard to how they are used.  In all cases you start profiling,
> do some work, and then fetch the profile.  They are all more or less
> the same.  I don't understand what is leading you to conclude that
> they are different.
>
> Heap profiling, on the other hand, really is different, and it is
> documented differently in runtime/pprof.
>
> Ian
>
>
> > On Sun, Oct 20, 2019 at 1:10 PM Ian Lance Taylor 
> wrote:
> >>
> >> On Sun, Oct 20, 2019 at 12:36 AM Nidhi Agrawal 
> wrote:
> >> >
> >> > Because it is explicitly written in the documentation here
> https://golang.org/pkg/net/http/pprof/ that we should set block profile
> rate at the start of application, unlike CPU profiling where the rate is
> being set internally before profiling starts.
> >>
> >> I'm likely missing something, but I'm looking at
> >> https://golang.org/pkg/net/http/pprof, and I don't see that.  I see
> >> that it says that you have to call runtime.SetBlockProfileRate or
> >> runtime.SetMutexProfileFraction, but I don't see anything that says
> >> that you have to call it at the start of the application.
> >>
> >> Ian
>

-- 
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/msgid/golang-nuts/CACcVEiWigvd2bhou2SLVZzpfoTX8CFEXHy90XOmZn5tzh3hX4w%40mail.gmail.com.

[go-nuts] Re: go 1.13.1 (linux x64): Build and Test is slower.

2019-10-20 Thread jambu 
Hey Stuart, I believe that it is most likely Go modules, I had tested 
adding go modules to my project and immediately my build times went from 
almost instant to noticeable. I reverted, and the build times went back to 
normal. I think this is because Go modules checks for module updates on 
each build. I have a private git in my import, and it prompted me for the 
git username/password each time I'd build too, which was the deciding 
factor for me. I could deal with a 5-10s builds, but having to enter my u/p 
each time was too much. Hope this helps


On Tuesday, October 15, 2019 at 10:22:49 AM UTC-4, Stuart Davies wrote:
>
> Ok I will just get on with it. I am not is a position to compare 
> performance when there are so many variables.
>
> I thought others might have had the same issue and there might be a simple 
> explanation. 
>
> We can close this discussion.
>
> On Tuesday, 15 October 2019 12:07:11 UTC+1, Stuart Davies wrote:
>>
>> Hi. 
>>
>> I use a low spec laptop that I take with me so I can work/play in the 
>> coffee shop!
>>
>> Since upgrading go to 1.13 I have noticed a significant slow down (2 to 3 
>> times) in build and build for test especially when debugging. 
>>
>> It is still fast compared to other languages I use but I was sooo 
>> impressed by the build times previously that I am very concious of the 
>> slower performance. 
>>
>> I am using VSCode ar an IDE and have made sure I am up to date with all 
>> the tools.
>>
>> I am using modules as well so perhaps this is the issue but all my code 
>> is local and I have a 'replace' in the go.mod file. 
>>
>> My project is outside GOPATH directory but GOPATH is still defined.
>>
>> Is ther esomthing I can do to restore the performance of is this 
>> 'Progress' and I will just have to et usd to it.
>>
>> Please keep up the good work. Go is the first language for years that I 
>> felt I could invest time in. As a Java dev for many years and the 
>> frustrations that brings, Go is a refreshing change. 
>> Please keep the language simple and dont get dragged in to the me-too 
>> feature debate. Go is a really great language already..
>>
>>
>>

-- 
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/msgid/golang-nuts/4fb7e0a7-b027-4d45-8b48-4403582a10c0%40googlegroups.com.