Re: [go-nuts] Re: What is pprof overhead like when gathering a profile?

2017-07-24 Thread 'Jaana Burcu Dogan' via golang-nuts
What we do is to periodically turn on profiling for X seconds, collect some
data and turn it off again. We do it at every once a while periodically. We
target a single or a group of instances in a large group.

On Mon, Jul 24, 2017 at 6:11 PM, Dave Cheney  wrote:

> Another option is to profile a % of requests. In the past I've done that
> by enabling profiling on a set % of application servers then extrapolating
> from there.
>
>
> On Tuesday, 25 July 2017 10:55:42 UTC+10, Jaana Burcu Dogan wrote:
>>
>> It would be very speculative to provide reference numbers without
>> actually seeing the specific program. You can benchmark the
>> latency/throughput with the CPU profiler on to see a realistic estimate.
>> FWIW, memory profiling, goroutine, thread create profiles are always on. At
>> Google, we continuously profile Go production services and it is safe to do
>> so.
>>
>>
>> On Monday, July 24, 2017 at 5:44:10 PM UTC-7, nat...@honeycomb.io wrote:
>>>
>>> Hello,
>>>
>>> I am curious what the performance impact of running pprof to collect
>>> information about CPU or memory usage is. Is it like strace where there
>>> could be a massive slowdown (up to 100x) or is it lower overhead, i.e.,
>>> safe to use in production? The article here -
>>> http://artem.krylysov.com/blog/2017/03/13/profiling-and-op
>>> timizing-go-web-applications/ - suggests that "one of the biggest pprof
>>> advantages is that it has low overhead and can be used in a production
>>> environment on a live traffic without any noticeable performance
>>> penalties". Is that accurate?
>>>
>>> Thanks!
>>>
>>> Nathan
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/e6lB8ENbIw8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: [golang-dev] Is there current support for Cloud Endpoints in Go

2017-01-18 Thread Jaana Burcu Dogan
+golang-nuts, bcc: golang-dev

On Tue, Jan 17, 2017 at 2:38 PM, Brad Fitzpatrick 
wrote:

> https://groups.google.com/forum/#!forum/google-appengine-go looks like
> the right place.
>
>
> On Tue, Jan 17, 2017 at 2:30 PM, Dewey Gaedcke  wrote:
>
>> Yesthat project has not been updated in 7 months and does not seem to
>> work with the latest endpoints
>> It's hard for me to imagine that Google advertises being able to use Go
>> with Endpoints on App Engine and yet does not support it.
>> We selected Go with the understanding that we could generate our client
>> lib from our API.if we have to throw this away and start over in a
>> different language, it's a serious loss for us.
>>
>> Can you recommend a group or site where this question would be more
>> relevant?
>> Thanks for your response!!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Deleting the /r/golang subreddit

2016-11-25 Thread Jaana Burcu Dogan
Please, find a better solution. Don't delete years of discussion and 
curated content. And, the Go subreddit is the work of the community over 
there and this question should be directed at them.

Minimizing the involvement and making it a unofficial space should be the 
first attempt. An unofficial and unmaintained r/golang doesn't sound as bad 
as a deleted one.

(As a side note, I am scared how our generation has normalized ethically 
corrupt actions from the authority and trying to hack around it rather than 
leaving in protest. I stopped using Reddit under my own name many years ago 
due to similar reasons.)

On Thursday, November 24, 2016 at 3:53:32 PM UTC-8, bradfitz wrote:
>
> In light of the CEO of Reddit admitting to editing user comments (see 
> dozen news stories today), I propose we delete the /r/golang subreddit.
>
> That is so beyond unethical and immature, I no longer want anything to do 
> with that site. I will be deleting my account on Reddit after backing up my 
> content, and I will no longer be a moderator of /r/golang.
>
> If other moderators of /r/golang feel strongly that it should remain, I 
> suppose you're welcome to keep it going.
>
> But if the other moderators want to abandon it and focus our conversation 
> elsewhere (or build a replacement), I'm happy to just delete /r/golang.
>
> Opinions?
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Package Management Survey Results

2016-11-19 Thread Jaana Burcu Dogan
Thanks for sharing the raw results.

On Thu, Nov 3, 2016 at 10:11 AM, Matt Farina  wrote:

> A couple months ago we had a package management survey. Since the survey
> closed the data has been fed into the package management committee.
>
> Now we are sharing the data, that was not asked to be kept private. This
> can be read at https://docs.google.com/document/d/15j_Q6RRX_LH6tu4DNDm-
> vAcWAUablqF4FsVsPijhEUg/edit?usp=sharing and the linked document from
> there.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

2016-10-28 Thread Jaana Burcu Dogan
On Thu, Oct 27, 2016 at 9:11 AM, Nate Finch  wrote:

> It seems like most of the problem with this whole situation comes from the
> wording of the "warning"
>
> Please consider this a warning from the Code of Conduct working group.
>>
>
>  "consider this a warning" can be interpreted as a threat (though the
> "Please" in front should soften it somewhat).  I don't think it was
> intended as such, but I think it's clear some people do read it that way.
> Perhaps just a rewording would prevent such a reaction in the future.
>

I agree.

The goal of the CoC should be creating awareness that a perspective is
might be perceived differently and let the OP know. The goal here isn't
policing the thoughts. Wording in the email is not helping here.

On the other hand, I do not think the issue is not the limitation of
expressing the truth as the OP mentions. If a person has a disability, you
don't seek for reasons to announce it on a public forum and then claim you
are the savior of truth. English proficiency issue is similar given native
and fluent users of the English language are clearly more advantaged in
English speaking communities.

We have many people in the community that are not necessarily using this
language as their primary language and IMHO solely focusing on this fact is
a distraction and received badly on the other hand.

I agree with some replies here saying that r/golang has far more worse.
Things look like they are cherry-picked because no one uses conduct@ and
once a single case is reported, it is perceived as people are reacting
excessively on a specific case.

-- 

> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Tooling experience feedback

2016-10-18 Thread 'Jaana Burcu Dogan' via golang-nuts
On Tue, Oct 18, 2016 at 12:34 PM, Jan Mercl <0xj...@gmail.com> wrote:

>
> On Tue, Oct 18, 2016 at 8:54 PM 'Jaana Burcu Dogan' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> The go tool already does a lot of things, perhaps too much of them.
>

Please contribute with specific items. Hiding complexity is also a goal we
want to achieve.


> The observation that newcomers have trouble to use it to their advantage
> is both correct and the evidence of its complexity. Adding new sub-commands
> has the potential to only make that worse, I'm afraid.
>
>
This is not a thread where we discuss what specifically will be added or
not. Major improvement ideas will be followed by proposals and will go
through the typical proposal process where you can give concrete feedback
about each item. This topic is about what could have improved by looking at
user's workflow and their actual daily interactions with the tools.


> --
>
> -j
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Tooling experience feedback

2016-10-18 Thread &#x27;Jaana Burcu Dogan' via golang-nuts
Hello gophers,

I am going to spend some time on improving the not-documented or
hard-to-use parts of the Go tools. I will mainly focus on go build and go
test. The work will consist of reorganizing manuals, proposing new
subcommands or flags to support commonly used multi-step things and so on.

To give you some concrete examples:

I have been in cases where users cannot find the build flags because they
are hidden. E.g.

$ go test -help
test [build/test flags] [packages] [build/test flags & test binary
flags]
...

requires you to know about where the build flags are. Some tools are
invisible for the newcomers.

The other example is about test coverage. It is so tedious that I need an
alias.

func gocover() {
go test -v -coverprofile=coverage.out && go tool cover
-html=coverage.out
}

I want to learn more about your experience, aliases, etc to propose
improvements and work on the most commonly suggested items. I also am
planning to go through this mailing list, stack overflow and other channels
to see the common complaints.

Feel free to reply to this thread or write to me privately.

Thanks,
JBD

-- 
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.
For more options, visit https://groups.google.com/d/optout.