[go-nuts] Golang binary on Mac OS error “operation not permitted”

[srinivas]

I'm trying to ship a golang binary inside a mac app. It is ideally just a 
http server with some basic functions on folders and files.

The binary seems to work just fine when I run it from a terminal but when I 
try calling it from my mac app programmatically it gives an error 
"operation not permitted" and quits.

Even after code-signing with a valid identity file I get the same error.

go build -ldflags -s .
codesign -s "Developer ID Application: *** *tesco" binaryFile

My Golang ENV:

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/srinivas/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -fdebug-prefix-map=/var/folders/3n/vpg5bnks45n75n
d91qh7sy3cgn/T/go-build925744934=/tmp/go-build -gno-record-gcc-switches 
-fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

-- 
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] understanding memory profile

['Robert Frangioso' via golang-nuts]

Thanks Dave!


> On Dec 5, 2017, at 7:57 PM, Dave Cheney  wrote:
> 
> The pprof packages are maintained elsewhere,
> https://github.com/google/pprof, we fork off a copy each major
> release.
> 
> On Wed, Dec 6, 2017 at 11:45 AM, Robert Frangioso
>  wrote:
>> 
>> I’ve noticed there appear to be changes with 1.9.2 from prior versions that
>> I have used. Still playing with it but has there been a redesign of the
>> profiling package I didn’t notice?
>> 
>> 
>> On Dec 5, 2017, at 4:51 PM, Dave Cheney  wrote:
>> 
>> Can you please check if this is happening with the current version of Go and
>> if so raise a bug, https://golang.org/issue/new.
>> 
>> 

-- 
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: Bcrypt isn't comparing stored password hash properly

[Gabriel Simmer]

The encoding hadn't occurred to me, I'll take a look. Neither return 
errors, as the value is properly thrown into the SQLite3 database. 

On Tuesday, December 5, 2017 at 12:36:26 PM UTC-8, matthe...@gmail.com 
wrote:
>
> In setup.go you aren't checking the errors from 
> bcrypt.GenerateFromPassword or bcrypt.CompareHashAndPassword, do either of 
> those return errors?
>
> The documentation for sqlite3 says "The value is a text string, stored 
> using the database encoding (UTF-8, UTF-16BE or UTF-16LE)", could it be 
> your database is interpreting your UTF-8 encoded text into a UTF-16 string?
>
>
> https://stackoverflow.com/questions/4532532/check-the-encoding-of-text-in-sqlite
>
> Matt
>
> On Tuesday, December 5, 2017 at 1:39:38 PM UTC-6, Gabriel Simmer wrote:
>>
>> Hey Gophers,
>>
>> I have a bit of a headscratcher for you guys today, hoping someone will 
>> be able to help me track down where I've gone wrong. I have an SQLite3 
>> database with user login info, including username, hashed password w/ 
>> bcrypt, and so on. I also have a "setup" method that is triggered on the 
>> first run of the application, which includes creating the database, setting 
>> an admin password and fetching assets. There's one hitch - the hashed 
>> password doesn't seem to be either:
>>
>>  - Stored properly
>>  - Hashed properly
>>  - Compared properly
>>
>> I've done some extensive testing and it appears bcrypt *is* hashing the 
>> password, and I can compare it successfully right after, and before I put 
>> it into the database. All good. However when I pull the hash from the 
>> database later (on user login), bcrypt doesn't see the hash and the 
>> password as equal and errors out. 
>>
>> Here is the GitHub repository's branch 
>> , if you want to fully test 
>> the application, but the relevant files are setup.go 
>>  and 
>> router/router.go 
>> . 
>> I've left in some debugging checks, and will happily answer any questions I 
>> haven't clarified. 
>>
>

-- 
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: understanding memory profile

[Sangjin Lee]

Mystery solved. It turns out it was coming from bytes.NewBuffer which was 
being invoked in the method I listed. Somehow that was attributed to the 
import line for bytes rather than the line of invocation.

On Tuesday, December 5, 2017 at 10:51:33 AM UTC-8, Dave Cheney wrote:
>
> No idea. Which version of Go are you using?

-- 
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: gomobile + go protobuf

[williamquintal95]

I have the same issue , did you find a solution ?

Le mercredi 8 novembre 2017 19:49:17 UTC-5, Jay Graves a écrit :
>
> I've been trying to use Protobufs as a data transport between go code and 
> native iOS and Android code. This has worked great on iOS as I can use this 
> to output go and objc code to work with the objects. 
> protoc --go_out=. --objc_out=. *.proto
>
> However, when I try to run 
> gomobile bind -target=android .
>
> I get the following error.
> Skabber:go-protobuf-test jay$ gomobile bind -target=android .
> gomobile: go build -pkgdir=/Users/jay/go/pkg/gomobile/pkg_android_arm -
> buildmode=c-shared -o=/var/folders/c3/8ydc1rk94kd7p9bcrkh85500gn/T/
> gomobile-work-563639487/android/src/main/jniLibs/armeabi-v7a/libgojni.so /
> var/folders/c3/8ydc1rk94kd7p9bcrkh85500gn/T/gomobile-work-563639487/
> androidlib/main.go failed: exit status 2
> # 
> _/var/folders/c3/8ydc1rk94kd7p9bcrkh85500gn/T/gomobile-work-563639487/gomobile_bind
> java_protobuftest.c:101:1: error: redefinition of 
> 'Java_protobuftest_Config_getCurrentversion'
> java_protobuftest.c:42:1: note: previous definition is here
> java_protobuftest.c:116:1: error: redefinition of 
> 'Java_protobuftest_Config_getUpgrademsg'
> java_protobuftest.c:58:1: note: previous definition is here
> java_protobuftest.c:131:1: error: redefinition of 
> 'Java_protobuftest_Config_getUpgradeurl'
> java_protobuftest.c:66:1: note: previous definition is here
> java_protobuftest.c:146:1: error: redefinition of 
> 'Java_protobuftest_Config_getDatatypes'
> java_protobuftest.c:50:1: note: previous definition is here
> java_protobuftest.c:221:1: error: redefinition of 
> 'Java_protobuftest_Config_DataType_getInvalidatedate'
> java_protobuftest.c:178:1: note: previous definition is here
> java_protobuftest.c:236:1: error: redefinition of 
> 'Java_protobuftest_Config_DataType_getUrl'
> java_protobuftest.c:186:1: note: previous definition is here
> java_protobuftest.c:251:1: error: redefinition of 
> 'Java_protobuftest_Config_DataType_getCache'
> java_protobuftest.c:170:1: note: previous definition is here
> java_protobuftest.c:266:1: error: redefinition of 
> 'Java_protobuftest_Config_DataType_getAutorefresh'
> java_protobuftest.c:162:1: note: previous definition is here
> java_protobuftest.c:341:1: error: redefinition of 
> 'Java_protobuftest_Config_DataTypes_getPackage'
> java_protobuftest.c:298:1: note: previous definition is here
> java_protobuftest.c:356:1: error: redefinition of 
> 'Java_protobuftest_Config_DataTypes_getRequest'
> java_protobuftest.c:306:1: note: previous definition is here
> java_protobuftest.c:371:1: error: redefinition of 
> 'Java_protobuftest_Config_DataTypes_getMilestones'
> java_protobuftest.c:290:1: note: previous definition is here
> java_protobuftest.c:386:1: error: redefinition of 
> 'Java_protobuftest_Config_DataTypes_getMilestonerange'
> java_protobuftest.c:282:1: note: previous definition is here
>
> Is this a problem with gomobile, protobuf, or my code?
>
> Thanks!
>

-- 
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: Dangers of package renaming

[Tim Peoples]

You may want to consider using a type alias -- similar to how 
golang.org/x/net/context  
is being transitioned to the standard library's context 
 package.

Also, Russ Cox wrote an excellent article about codebase refactoring 
; I highly recommend it.


On Saturday, December 2, 2017 at 7:33:06 AM UTC-8, Jonathan Hall wrote:
>
> I maintain an open-source Go package with a few dozen followers.  (
> github.com/flimzy/kivik)
>
> I'm planning to transfer/rename the package to a new organization (new 
> package name to be: github.com/go-kivik/kivik).
>
> I understand that GitHub will maintain a redirect from the old location to 
> the new one, so in theory, old imports will continue working.
>
> But my question is: Are there any dangers I need to consider when making 
> this change, and is there anything I can do to help mitigate such dangers?  
> I ask mainly because I've read of some nightmares related to package 
> renaming (example: 
> https://github.com/sirupsen/logrus/issues/570#issuecomment-313933276), 
> and want to do everything possible to prevent such problems for my own 
> package.  (To be clear: I don't think the Sirupsen problem in particular 
> will affect me, since it's not just a capitalization change).
>
> Keep in mind that the package has sub-packages as a dependencies (i.e. 
> github.com/flimzy/kivik dependson github.com/flimzy/kivik/errors), in 
> case this complicates things.
>
> Thank you,
>
> Jonathan
>
>

-- 
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: Bcrypt isn't comparing stored password hash properly

[matthewjuran]

In setup.go you aren't checking the errors from bcrypt.GenerateFromPassword 
or bcrypt.CompareHashAndPassword, do either of those return errors?

The documentation for sqlite3 says "The value is a text string, stored 
using the database encoding (UTF-8, UTF-16BE or UTF-16LE)", could it be 
your database is interpreting your UTF-8 encoded text into a UTF-16 string?

https://stackoverflow.com/questions/4532532/check-the-encoding-of-text-in-sqlite

Matt

On Tuesday, December 5, 2017 at 1:39:38 PM UTC-6, Gabriel Simmer wrote:
>
> Hey Gophers,
>
> I have a bit of a headscratcher for you guys today, hoping someone will be 
> able to help me track down where I've gone wrong. I have an SQLite3 
> database with user login info, including username, hashed password w/ 
> bcrypt, and so on. I also have a "setup" method that is triggered on the 
> first run of the application, which includes creating the database, setting 
> an admin password and fetching assets. There's one hitch - the hashed 
> password doesn't seem to be either:
>
>  - Stored properly
>  - Hashed properly
>  - Compared properly
>
> I've done some extensive testing and it appears bcrypt *is* hashing the 
> password, and I can compare it successfully right after, and before I put 
> it into the database. All good. However when I pull the hash from the 
> database later (on user login), bcrypt doesn't see the hash and the 
> password as equal and errors out. 
>
> Here is the GitHub repository's branch 
> , if you want to fully test 
> the application, but the relevant files are setup.go 
>  and 
> router/router.go 
> . 
> I've left in some debugging checks, and will happily answer any questions I 
> haven't clarified. 
>

-- 
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: understanding memory profile

[Dave Cheney]

No idea. Which version of Go are you using?

-- 
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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

No problems! If I can get a beta running I'll revisit this thread.

Cheers,

On Tue, Dec 5, 2017, 19:41 Rick Hudson  wrote:

> Henrik,
> Thanks for the kind offer but there isn't much the runtime team can do
> with the logs since 1.9 isn't likely to be changed due to this issue.
>
>
>
> On Tue, Dec 5, 2017 at 10:43 AM, Henrik Johansson 
> wrote:
>
>> I would gladly help with this but afaik Heroku only makes stable versions
>> available:
>> https://github.com/heroku/heroku-buildpack-go/blob/master/data.json
>> I guess I could deploy a docker container but I don't know if it changes
>> everything and I doubt I have time before christmas at least.
>>
>> Maybe someone more versed in Herokus Go support can chime in on if it is
>> possible.
>>
>> I will provide the logs from tonight though. Do you want them zipped here
>> in the thread?
>>
>>
>> tis 5 dec. 2017 kl 15:37 skrev Rick Hudson :
>>
>>> Glad to have helped. The runtime team would be interested in seeing what
>>> these pauses look like in the beta. If you have the time could you send
>>> them to us after the beta comes out.
>>>
>>>
>>> On Tue, Dec 5, 2017 at 9:06 AM, Henrik Johansson 
>>> wrote:
>>>
 Ok so it's not bad, thats good!

 The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
 (Beta) provides.
 These must be sums in the given graph bucket which may for a 24H period
 add up to the high numbers I guess.

 I will let it run over night and see what it looks like tomorrow, thx
 for your thoughts on this!

 tis 5 dec. 2017 kl 14:58 skrev :

> The wall clock is the first set of numbers, the second set is CPU. So
> 8P running for 8ms wall clock will result in 64ms CPU. The word "wall" was
> dropped to keep the line short.
>
> There will be a beta out in the proverbial next few days that could
> help reduce even these STW times. The original post talked about 20 second
> and 400 and 900 ms pauses. From what I'm seeing here it is hard to
> attribute them to GC STW pauses.
>
> Also the GC is taking up (a rounded) 0% of the CPU which is pretty
> good (insert fancy new emoji).  It is also doing it with a budget of 10 or
> 11 MBtyes on a machine that likely has 8 GB of Ram. To further test 
> whether
> this is a GC issue or not try increasing GOGC until the MB goal on the
> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x 
> or
> 100x and if your tail latency is a GC problem the 99%tile latency numbers
> will become 99.9%tile or 99.99%tile numbers.
>
> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson
> wrote:
>
>> I am watching with childlike fascination...
>> This is interesting perhaps:
>>
>> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms
>> cpu, 8->8->4 MB, 9 MB goal, 8 P
>> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0
>> ms cpu, 9->9->5 MB, 10 MB
>>  goal,
>> 8 P
>>
>> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms
>> cpu, 10->11->4 MB, 11 MB
>>  goal,
>> 8 P
>>
>> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms
>> cpu, 8->9->5 MB, 9 MB goal, 8 P
>> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
>> 9->10->5 MB, 10 MB
>>  goal,
>> 8 P
>>
>> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>>
>>
>>
>> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney :
>>
> Oh yeah, I forgot someone added that a while back. That should work.
>>>
>>> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson 
>>> wrote:
>>> > So it has to run the program? I thought I saw "logfile" scenario
>>> in the
>>> > examples?
>>> >
>>> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
>>> > cat stderr.log | gcvis
>>> >
>>> > I have shuffled the Heroku logs into Papertrail so I should be
>>> able to
>>> > extract the log lines from there.
>>> >
>>> >
>>> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney :
>>> >>
>>> >> Probably not for your scenario, gcviz assumes it can run your
>>> program
>>> >> as a child.
>>> >>
>>>
>> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson <
>>> dahan...@gmail.com>
>>
>>
>>> >> wrote:
>>> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney
>>> is it a
>>> >> > good
>>> >> > choice for inspecting the gc logs?
>>> >> >
>>> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <
>>> 

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[Rick Hudson]

Henrik,
Thanks for the kind offer but there isn't much the runtime team can do with
the logs since 1.9 isn't likely to be changed due to this issue.



On Tue, Dec 5, 2017 at 10:43 AM, Henrik Johansson 
wrote:

> I would gladly help with this but afaik Heroku only makes stable versions
> available:  https://github.com/heroku/heroku-buildpack-go/blob/
> master/data.json
> I guess I could deploy a docker container but I don't know if it changes
> everything and I doubt I have time before christmas at least.
>
> Maybe someone more versed in Herokus Go support can chime in on if it is
> possible.
>
> I will provide the logs from tonight though. Do you want them zipped here
> in the thread?
>
>
> tis 5 dec. 2017 kl 15:37 skrev Rick Hudson :
>
>> Glad to have helped. The runtime team would be interested in seeing what
>> these pauses look like in the beta. If you have the time could you send
>> them to us after the beta comes out.
>>
>>
>> On Tue, Dec 5, 2017 at 9:06 AM, Henrik Johansson 
>> wrote:
>>
>>> Ok so it's not bad, thats good!
>>>
>>> The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
>>> (Beta) provides.
>>> These must be sums in the given graph bucket which may for a 24H period
>>> add up to the high numbers I guess.
>>>
>>> I will let it run over night and see what it looks like tomorrow, thx
>>> for your thoughts on this!
>>>
>>> tis 5 dec. 2017 kl 14:58 skrev :
>>>
 The wall clock is the first set of numbers, the second set is CPU. So
 8P running for 8ms wall clock will result in 64ms CPU. The word "wall" was
 dropped to keep the line short.

 There will be a beta out in the proverbial next few days that could
 help reduce even these STW times. The original post talked about 20 second
 and 400 and 900 ms pauses. From what I'm seeing here it is hard to
 attribute them to GC STW pauses.

 Also the GC is taking up (a rounded) 0% of the CPU which is pretty good
 (insert fancy new emoji).  It is also doing it with a budget of 10 or 11
 MBtyes on a machine that likely has 8 GB of Ram. To further test whether
 this is a GC issue or not try increasing GOGC until the MB goal on the
 gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or
 100x and if your tail latency is a GC problem the 99%tile latency numbers
 will become 99.9%tile or 99.99%tile numbers.

 On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson
 wrote:

> I am watching with childlike fascination...
> This is interesting perhaps:
>
> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms
> cpu, 8->8->4 MB, 9 MB goal, 8 P
> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms
> cpu, 9->9->5 MB, 10 MB
>  goal, 8
> P
>
> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms
> cpu, 10->11->4 MB, 11 MB
>  goal, 8
> P
>
> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
> 8->9->5 MB, 9 MB goal, 8 P
> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
> 9->10->5 MB, 10 MB
>  goal, 8
> P
>
> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>
>
>
> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney :
>
 Oh yeah, I forgot someone added that a while back. That should work.
>>
>> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson 
>> wrote:
>> > So it has to run the program? I thought I saw "logfile" scenario in
>> the
>> > examples?
>> >
>> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
>> > cat stderr.log | gcvis
>> >
>> > I have shuffled the Heroku logs into Papertrail so I should be able
>> to
>> > extract the log lines from there.
>> >
>> >
>> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney :
>> >>
>> >> Probably not for your scenario, gcviz assumes it can run your
>> program
>> >> as a child.
>> >>
>>
> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson <
>> dahan...@gmail.com>
>
>
>> >> wrote:
>> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney
>> is it a
>> >> > good
>> >> > choice for inspecting the gc logs?
>> >> >
>> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <
>> dahan...@gmail.com>:
>> >> >>
>> >> >> I have just added the gc tracing and it looks like this more or
>> less
>> >> >> all
>> >> >> the time:
>> >> >>
>> >> >> gc 78 @253.095s 0
>> %:
>> 0.032+3.3+0.46 ms clock, 

[go-nuts] Re: understanding memory profile

[Sangjin Lee]

Thanks for the pointer! I am still puzzled by the former (allocation 
associated with the import line). I thought it could be an init() function 
in this file, but that does not explain it...

On Monday, December 4, 2017 at 5:47:09 PM UTC-8, Dave Cheney wrote:
>
>
>
> On Tuesday, 5 December 2017 12:09:54 UTC+11, Sangjin Lee wrote:
>>
>> A couple of questions on understanding go pprof's memory profile...
>>
>> When I list a certain function (with --alloc_objects), I see an 
>> allocation number associated with an import line mysteriously. I am pretty 
>> certain I can rule out any source line offset. For example,
>>
>> (pprof) list foo
>> Total: 534804146
>> ROUTINE  (snip)
>>   24057960   27540717 (flat, cum)  5.15% of Total
>>  .  .  1:package protocol
>>  .  .  2:
>>  .  .  3:import (
>>   12092676   12092676  4:   "bytes"
>>  .  .  5:   "fmt"
>>  .  .  6:   "net/url"
>>  .  .  7:   "strconv"
>>  .  .  8:   "strings"
>>  .  .  9:   "time"
>>  .  . 10:   "unicode"
>>  .  . 11:)
>>
>> Any idea how to interpret this?
>>
>> In addition, is there a way to drill down further into exactly what type 
>> of memory allocation is contributing to the allocation when I list a 
>> function? The tree/web/pdf view doesn't break down further function names 
>> (only shows the boxes with what I believe is the individual allocation 
>> size). I'm kind of guessing from the line of code on what it is, but it'd 
>> be great if there is a way to track down exactly what type of memory 
>> allocation it is (string copy, map growth, byte allocation, etc.). For 
>> example,
>>
>> (pprof) list add
>> Total: 534804146
>> ROUTINE  (snip)
>>   17248777   17248777 (flat, cum)  3.23% of Total
>>  .  .220: l *logger
>>  .  .221:}
>>  .  .222:
>>  .  .223:func (l *logger) add(data 
>> map[string]interface{}) {
>>  .  .224: if id := l.Id(); id != "" {
>>   17248777   17248777225: data[ID] = id
>>  .  .226: }
>>  .  .227:}
>>  .  .228:
>>
>> where id is a string.
>>
>
> The allocations are taking the address of the value of id when it is boxed 
> into an interface{} 
>

-- 
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: are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

['simon place' via golang-nuts]

for people possibly scanning this later;

when you say;  "it won't store the address of the value, but will make a 
copy."

i think this is correct/clearer;  "it won't store the address of the value, 
but will make a copy, and store its address."


On Tuesday, 5 December 2017 07:41:51 UTC, Axel Wagner wrote:
>
> Slight correction (I think): If you store a non-pointer in an interface, 
> it won't store the address of the value (variable? values don't have an 
> address, strictly speaking), but will make a copy. Otherwise, this wouldn't 
> work: https://play.golang.org/p/P1YwxBk7lR
> You can also see these effects here (and feel free to play around a bit): 
> https://play.golang.org/p/GqAUn31A1y
>
>

-- 
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: are interface calls to empty methods optimized away - so there is no function call overhead beyond the dereference/jump?

['simon place' via golang-nuts]

nice, so from a users point of view, (apart from it making no functional 
difference.), having interfaces of pointer types incurs no run-time 
overhead (well apart from the storage for the type info.).

-- 
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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

I would gladly help with this but afaik Heroku only makes stable versions
available:
https://github.com/heroku/heroku-buildpack-go/blob/master/data.json
I guess I could deploy a docker container but I don't know if it changes
everything and I doubt I have time before christmas at least.

Maybe someone more versed in Herokus Go support can chime in on if it is
possible.

I will provide the logs from tonight though. Do you want them zipped here
in the thread?


tis 5 dec. 2017 kl 15:37 skrev Rick Hudson :

> Glad to have helped. The runtime team would be interested in seeing what
> these pauses look like in the beta. If you have the time could you send
> them to us after the beta comes out.
>
>
> On Tue, Dec 5, 2017 at 9:06 AM, Henrik Johansson 
> wrote:
>
>> Ok so it's not bad, thats good!
>>
>> The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
>> (Beta) provides.
>> These must be sums in the given graph bucket which may for a 24H period
>> add up to the high numbers I guess.
>>
>> I will let it run over night and see what it looks like tomorrow, thx for
>> your thoughts on this!
>>
>> tis 5 dec. 2017 kl 14:58 skrev :
>>
>>> The wall clock is the first set of numbers, the second set is CPU. So 8P
>>> running for 8ms wall clock will result in 64ms CPU. The word "wall" was
>>> dropped to keep the line short.
>>>
>>> There will be a beta out in the proverbial next few days that could help
>>> reduce even these STW times. The original post talked about 20 second and
>>> 400 and 900 ms pauses. From what I'm seeing here it is hard to attribute
>>> them to GC STW pauses.
>>>
>>> Also the GC is taking up (a rounded) 0% of the CPU which is pretty good
>>> (insert fancy new emoji).  It is also doing it with a budget of 10 or 11
>>> MBtyes on a machine that likely has 8 GB of Ram. To further test whether
>>> this is a GC issue or not try increasing GOGC until the MB goal on the
>>> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or
>>> 100x and if your tail latency is a GC problem the 99%tile latency numbers
>>> will become 99.9%tile or 99.99%tile numbers.
>>>
>>> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson wrote:
>>>
 I am watching with childlike fascination...
 This is interesting perhaps:

 gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu,
 8->8->4 MB, 9 MB goal, 8 P
 gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms
 cpu, 9->9->5 MB, 10 MB
  goal, 8
 P

 ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms
 cpu, 10->11->4 MB, 11 MB
  goal, 8
 P

 gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
 8->9->5 MB, 9 MB goal, 8 P
 gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
 9->10->5 MB, 10 MB
  goal, 8
 P

 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?



 tis 5 dec. 2017 kl 08:25 skrev Dave Cheney :

>>> Oh yeah, I forgot someone added that a while back. That should work.
>
> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson 
> wrote:
> > So it has to run the program? I thought I saw "logfile" scenario in
> the
> > examples?
> >
> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
> > cat stderr.log | gcvis
> >
> > I have shuffled the Heroku logs into Papertrail so I should be able
> to
> > extract the log lines from there.
> >
> >
> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney :
> >>
> >> Probably not for your scenario, gcviz assumes it can run your
> program
> >> as a child.
> >>
>
 >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson  >


> >> wrote:
> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney is
> it a
> >> > good
> >> > choice for inspecting the gc logs?
> >> >
> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <
> dahan...@gmail.com>:
> >> >>
> >> >> I have just added the gc tracing and it looks like this more or
> less
> >> >> all
> >> >> the time:
> >> >>
> >> >> gc 78 @253.095s 0
> %:
> 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
> >> >> cpu,
> >> >> 11->12->4 MB, 12 MB
>  goal, 8
> P
> >> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock,
> 0.16+0.19/3.6/1.2+1.3 ms
> >> >> cpu,
> >> >> 9->9->4 MB, 10 MB
>  goal, 8
> P
> >> >> gc 80 @253.120s 

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[Rick Hudson]

Glad to have helped. The runtime team would be interested in seeing what
these pauses look like in the beta. If you have the time could you send
them to us after the beta comes out.


On Tue, Dec 5, 2017 at 9:06 AM, Henrik Johansson 
wrote:

> Ok so it's not bad, thats good!
>
> The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
> (Beta) provides.
> These must be sums in the given graph bucket which may for a 24H period
> add up to the high numbers I guess.
>
> I will let it run over night and see what it looks like tomorrow, thx for
> your thoughts on this!
>
> tis 5 dec. 2017 kl 14:58 skrev :
>
>> The wall clock is the first set of numbers, the second set is CPU. So 8P
>> running for 8ms wall clock will result in 64ms CPU. The word "wall" was
>> dropped to keep the line short.
>>
>> There will be a beta out in the proverbial next few days that could help
>> reduce even these STW times. The original post talked about 20 second and
>> 400 and 900 ms pauses. From what I'm seeing here it is hard to attribute
>> them to GC STW pauses.
>>
>> Also the GC is taking up (a rounded) 0% of the CPU which is pretty good
>> (insert fancy new emoji).  It is also doing it with a budget of 10 or 11
>> MBtyes on a machine that likely has 8 GB of Ram. To further test whether
>> this is a GC issue or not try increasing GOGC until the MB goal on the
>> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or
>> 100x and if your tail latency is a GC problem the 99%tile latency numbers
>> will become 99.9%tile or 99.99%tile numbers.
>>
>> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson wrote:
>>
>>> I am watching with childlike fascination...
>>> This is interesting perhaps:
>>>
>>> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu,
>>> 8->8->4 MB, 9 MB goal, 8 P
>>> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms
>>> cpu, 9->9->5 MB, 10 MB
>>>  goal, 8 P
>>>
>>> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms cpu,
>>> 10->11->4 MB, 11 MB
>>>  goal, 8 P
>>>
>>> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
>>> 8->9->5 MB, 9 MB goal, 8 P
>>> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
>>> 9->10->5 MB, 10 MB
>>>  goal, 8 P
>>>
>>> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>>>
>>>
>>>
>>> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney :
>>>
>> Oh yeah, I forgot someone added that a while back. That should work.

 On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson 
 wrote:
 > So it has to run the program? I thought I saw "logfile" scenario in
 the
 > examples?
 >
 > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
 > cat stderr.log | gcvis
 >
 > I have shuffled the Heroku logs into Papertrail so I should be able to
 > extract the log lines from there.
 >
 >
 > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney :
 >>
 >> Probably not for your scenario, gcviz assumes it can run your program
 >> as a child.
 >>

>>> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson 
>>>
>>>
 >> wrote:
 >> > I found https://github.com/davecheney/gcvis from +Dave Cheney is
 it a
 >> > good
 >> > choice for inspecting the gc logs?
 >> >
 >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson <
 dahan...@gmail.com>:
 >> >>
 >> >> I have just added the gc tracing and it looks like this more or
 less
 >> >> all
 >> >> the time:
 >> >>
 >> >> gc 78 @253.095s 0
 %:
 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
 >> >> cpu,
 >> >> 11->12->4 MB, 12 MB
  goal, 8 P
 >> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock,
 0.16+0.19/3.6/1.2+1.3 ms
 >> >> cpu,
 >> >> 9->9->4 MB, 10 MB
  goal, 8 P
 >> >> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock,
 0.17+0.27/4.8/0.006+18 ms
 >> >> cpu,
 >> >> 8->8->4 MB, 9 MB goal, 8 P
 >> >> gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock,
 0.15+0.73/3.9/3.1+0.81 ms
 >> >> cpu, 9->9->5 MB, 10 MB
  goal, 8 P
 >> >>
 >> >> Heroku already reports a SW of 343 ms but I can't find it by
 manual
 >> >> inspection. I will download the logs later today and try to
 generate
 >> >> realistic load.
 >> >> What is the overhead of running like this, aside from the obvious
 extra
 >> >> logging?
 >> >> Are there any automatic tools to analyze these logs?
 >> >>

Re: [go-nuts] [ANN] gometalinter v2.0.0 released - much faster linting

[Shawn Milochik]

Thanks for this! If the people who care most about their code use linters,
what does that say about those who write the linters? 

-- 
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: GC SW times on Heroku (Beta metrics)

[Henrik Johansson]

Ok so it's not bad, thats good!

The inital ~20 sec numbers come from the graphs that Herokus Go Metrics
(Beta) provides.
These must be sums in the given graph bucket which may for a 24H period add
up to the high numbers I guess.

I will let it run over night and see what it looks like tomorrow, thx for
your thoughts on this!

tis 5 dec. 2017 kl 14:58 skrev :

> The wall clock is the first set of numbers, the second set is CPU. So 8P
> running for 8ms wall clock will result in 64ms CPU. The word "wall" was
> dropped to keep the line short.
>
> There will be a beta out in the proverbial next few days that could help
> reduce even these STW times. The original post talked about 20 second and
> 400 and 900 ms pauses. From what I'm seeing here it is hard to attribute
> them to GC STW pauses.
>
> Also the GC is taking up (a rounded) 0% of the CPU which is pretty good
> (insert fancy new emoji).  It is also doing it with a budget of 10 or 11
> MBtyes on a machine that likely has 8 GB of Ram. To further test whether
> this is a GC issue or not try increasing GOGC until the MB goal on the
> gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or
> 100x and if your tail latency is a GC problem the 99%tile latency numbers
> will become 99.9%tile or 99.99%tile numbers.
>
> On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson wrote:
>
>> I am watching with childlike fascination...
>> This is interesting perhaps:
>>
>> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu,
>> 8->8->4 MB, 9 MB goal, 8 P
>> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms
>> cpu, 9->9->5 MB, 10 MB
>>  goal, 8 P
>>
>> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms cpu,
>> 10->11->4 MB, 11 MB
>>  goal, 8 P
>>
>> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu,
>> 8->9->5 MB, 9 MB goal, 8 P
>> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu,
>> 9->10->5 MB, 10 MB
>>  goal, 8 P
>>
>> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>>
>>
>>
>> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney :
>>
> Oh yeah, I forgot someone added that a while back. That should work.
>>>
>>> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson 
>>> wrote:
>>> > So it has to run the program? I thought I saw "logfile" scenario in the
>>> > examples?
>>> >
>>> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
>>> > cat stderr.log | gcvis
>>> >
>>> > I have shuffled the Heroku logs into Papertrail so I should be able to
>>> > extract the log lines from there.
>>> >
>>> >
>>> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney :
>>> >>
>>> >> Probably not for your scenario, gcviz assumes it can run your program
>>> >> as a child.
>>> >>
>>>
>> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson 
>>
>>
>>> >> wrote:
>>> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney is
>>> it a
>>> >> > good
>>> >> > choice for inspecting the gc logs?
>>> >> >
>>> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson >> >:
>>> >> >>
>>> >> >> I have just added the gc tracing and it looks like this more or
>>> less
>>> >> >> all
>>> >> >> the time:
>>> >> >>
>>> >> >> gc 78 @253.095s 0
>>> %:
>>> 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
>>> >> >> cpu,
>>> >> >> 11->12->4 MB, 12 MB
>>>  goal, 8 P
>>> >> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3
>>> ms
>>> >> >> cpu,
>>> >> >> 9->9->4 MB, 10 MB
>>>  goal, 8 P
>>> >> >> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/0.006+18
>>> ms
>>> >> >> cpu,
>>> >> >> 8->8->4 MB, 9 MB goal, 8 P
>>> >> >> gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock,
>>> 0.15+0.73/3.9/3.1+0.81 ms
>>> >> >> cpu, 9->9->5 MB, 10 MB
>>>  goal, 8 P
>>> >> >>
>>> >> >> Heroku already reports a SW of 343 ms but I can't find it by manual
>>> >> >> inspection. I will download the logs later today and try to
>>> generate
>>> >> >> realistic load.
>>> >> >> What is the overhead of running like this, aside from the obvious
>>> extra
>>> >> >> logging?
>>> >> >> Are there any automatic tools to analyze these logs?
>>> >> >>
>>> >> >> lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson <
>>> dahan...@gmail.com>:
>>> >> >>>
>>> >> >>> I am sorry, I was unclear. The app uses very little ram but the
>>> >> >>> provisioned available memory is 512 MB.
>>> >> >>>
>>> >> >>> I will try to experiment with GC toggles as you suggest and report
>>> >> >>> back.
>>> >> >>>
>>> >> >>> Thx!
>>> >> >>>
>>> >> >>>
>>> >> >>> On Sat, Dec 2, 

Re: [go-nuts] Re: GC SW times on Heroku (Beta metrics)

[rlh]

The wall clock is the first set of numbers, the second set is CPU. So 8P 
running for 8ms wall clock will result in 64ms CPU. The word "wall" was 
dropped to keep the line short.

There will be a beta out in the proverbial next few days that could help 
reduce even these STW times. The original post talked about 20 second and 
400 and 900 ms pauses. From what I'm seeing here it is hard to attribute 
them to GC STW pauses.

Also the GC is taking up (a rounded) 0% of the CPU which is pretty good 
(insert fancy new emoji).  It is also doing it with a budget of 10 or 11 
MBtyes on a machine that likely has 8 GB of Ram. To further test whether 
this is a GC issue or not try increasing GOGC until the MB goal on the 
gctrace line is 10x or 100x larger. This will reduce GC frequency by 10x or 
100x and if your tail latency is a GC problem the 99%tile latency numbers 
will become 99.9%tile or 99.99%tile numbers.

On Tuesday, December 5, 2017 at 2:39:53 AM UTC-5, Henrik Johansson wrote:
>
> I am watching with childlike fascination...
> This is interesting perhaps:
>
> gc 130 @2834.158s 0%: 0.056+3.4+2.9 ms clock, 0.45+2.8/5.6/0+23 ms cpu, 
> 8->8->4 MB, 9 MB goal, 8 P 
> gc 131 @2834.178s 0%: 0.023+7.3+0.12 ms clock, 0.18+1.2/5.4/9.2+1.0 ms 
> cpu, 9->9->5 MB, 10 MB goal, 8 P 
>
> ---> gc 132 @2836.882s 0%: 3.5+34+8.0 ms clock, 28+1.6/3.8/27+64 ms cpu, 
> 10->11->4 MB, 11 MB goal, 8 P 
>
> gc 133 @2836.961s 0%: 0.022+14+1.0 ms clock, 0.18+2.1/12/0+8.4 ms cpu, 
> 8->9->5 MB, 9 MB goal, 8 P 
> gc 134 @2837.010s 0%: 7.0+18+0.16 ms clock, 56+14/21/1.6+1.2 ms cpu, 
> 9->10->5 MB, 10 MB goal, 8 P 
>
> 28 + 64 ms SW (if I understand this correctly) to collect what 6-7 MB?
>
>
>
> tis 5 dec. 2017 kl 08:25 skrev Dave Cheney  >:
>
>> Oh yeah, I forgot someone added that a while back. That should work.
>>
>> On Tue, Dec 5, 2017 at 6:23 PM, Henrik Johansson > > wrote:
>> > So it has to run the program? I thought I saw "logfile" scenario in the
>> > examples?
>> >
>> > GODEBUG=gctrace=1 godoc -index -http=:6060 2> stderr.log
>> > cat stderr.log | gcvis
>> >
>> > I have shuffled the Heroku logs into Papertrail so I should be able to
>> > extract the log lines from there.
>> >
>> >
>> > tis 5 dec. 2017 kl 08:10 skrev Dave Cheney > >:
>> >>
>> >> Probably not for your scenario, gcviz assumes it can run your program
>> >> as a child.
>> >>
>> >> On Tue, Dec 5, 2017 at 6:07 PM, Henrik Johansson > >
>> >> wrote:
>> >> > I found https://github.com/davecheney/gcvis from +Dave Cheney is it 
>> a
>> >> > good
>> >> > choice for inspecting the gc logs?
>> >> >
>> >> > tis 5 dec. 2017 kl 07:57 skrev Henrik Johansson > >:
>> >> >>
>> >> >> I have just added the gc tracing and it looks like this more or less
>> >> >> all
>> >> >> the time:
>> >> >>
>> >> >> gc 78 @253.095s 0 
>> %: 
>> 0.032+3.3+0.46 ms clock, 0.26+0.24/2.6/2.4+3.6 ms
>> >> >> cpu,
>> >> >> 11->12->4 MB, 12 MB goal, 8 P
>> >> >> gc 79 @253.109s 0%: 0.021+2.1+0.17 ms clock, 0.16+0.19/3.6/1.2+1.3 
>> ms
>> >> >> cpu,
>> >> >> 9->9->4 MB, 10 MB goal, 8 P
>> >> >> gc 80 @253.120s 0%: 0.022+2.8+2.2 ms clock, 0.17+0.27/4.8/0.006+18 
>> ms
>> >> >> cpu,
>> >> >> 8->8->4 MB, 9 MB goal, 8 P
>> >> >> gc 81 @253.138s 0%: 0.019+2.3+0.10 ms clock, 0.15+0.73/3.9/3.1+0.81 
>> ms
>> >> >> cpu, 9->9->5 MB, 10 MB goal, 8 P
>> >> >>
>> >> >> Heroku already reports a SW of 343 ms but I can't find it by manual
>> >> >> inspection. I will download the logs later today and try to generate
>> >> >> realistic load.
>> >> >> What is the overhead of running like this, aside from the obvious 
>> extra
>> >> >> logging?
>> >> >> Are there any automatic tools to analyze these logs?
>> >> >>
>> >> >> lör 2 dec. 2017 kl 22:36 skrev Henrik Johansson > >:
>> >> >>>
>> >> >>> I am sorry, I was unclear. The app uses very little ram but the
>> >> >>> provisioned available memory is 512 MB.
>> >> >>>
>> >> >>> I will try to experiment with GC toggles as you suggest and report
>> >> >>> back.
>> >> >>>
>> >> >>> Thx!
>> >> >>>
>> >> >>>
>> >> >>> On Sat, Dec 2, 2017, 22:18 rlh via golang-nuts
>> >> >>>  wrote:
>> >> 
>> >>  Hard telling what it going on. 35MB, even for 1 CPU, seems very
>> >>  small.
>> >>  Most modern system provision more than 1GB per HW thread though 
>> I've
>> >>  seen
>> >>  some provision as little as 512MB. GOGC (SetGCPercent) can be 
>> adjust
>> >>  so that
>> >>  the application uses more of the available RAM. Running with
>> >>  GODEBUG=gctrace=1 will give you a sense of the GC's view of the
>> >>  application.
>> >> 
>> >>  In any case these kinds of numbers, running on a real systems, and
>> >>  duplicatable on tip are worth filing an issue.
>> >> 
>> >>  On Saturday, December 2, 2017 at 3:02:30 AM UTC-5, Henrik 
>> 

Re: [go-nuts] [ANN] gometalinter v2.0.0 released - much faster linting

[Steven Hartland]

On 05/12/2017 05:16, Alec Thomas wrote:

Hello,

Through the efforts of many contributors, and in particular those of 
Daniel Nephin, v2.0.0 has been released. You can grab it here:


  https://github.com/alecthomas/gometalinter/releases/tag/v2.0.0

The biggest change since v1.x is that linting is now MUCH more 
efficient, thanks to the changes by Daniel. Instead of invoking each 
linter for every directory, linters are invoked the minimum number of 
times necessary by passing as many directories, packages or files as 
they will accept in a single invocation.


The configuration format has also changed, but should be mostly 
backwards compatible.


Another major change is that from now on we will be releasing binary 
packages. This also means that: gometalinter's management of linter 
installation will soon be deprecated, and eventually removed, and that 
gopkg.in will no longer be used.


Going forward we have several interesting things planned for gometalinter:

1. Support for in-process invocation of linters via an interface + 
adapters. See https://github.com/alecthomas/gometalinter/issues/380. 
This should make linting even more efficient, as packages will only 
need to be parsed/compiled once, and the FileSet (etc.) can be reused.
2. Configuration handling will be rewritten/rethought. This will 
encompass automatic .gometalinterrc loading, among other things.
This is great news Alex, thanks for everyone's hard work #2 
(.gometalinterrc loading) is the killer feature for us.


Currently we have to invoke gometalinter for each package on the command 
line separately, which prevents any benefits of v2. speedup.



3. Lots of internal refactoring to clean up the codebase.

As always, if you encounter any problems please create a new issue.



    Regards
    Steve

--
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] [ANN] gometalinter v2.0.0 released - much faster linting

[Shulhan]

On Mon, 4 Dec 2017 21:16:30 -0800 (PST)
Alec Thomas  wrote:

> Hello,
> 
> Through the efforts of many contributors, and in particular those of
> Daniel Nephin, v2.0.0 has been released. You can grab it here:
> 
> https://github.com/alecthomas/gometalinter/releases/tag/v2.0.0
> 

On behalf of my team, I would like to say thank you for this project
and to the maintainer of linter tools.


Regards,
Shulhan

-- 
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.