[go-nuts] Re: weblist in go tool pprof does not work for me
Hello,
Did you find a solution to this problem? I have the same problem with
weblist.
All the best,
Sergey
пятница, 24 июня 2022 г. в 15:27:11 UTC+3, Jochen Voss:
> Hello,
>
> For a while, the "weblist" command in go tool pprof has been broken for me
> ("list" still works). Is this a known issue? What can I do to fix this?
>
> What I am doing:
>
> - I am using "go version go1.18.3 darwin/arm64" on a MacBook Pro (M1 Pro
> processor).
> - I am profiling one of my unit tests using the following command:
> go test -run '^TestAll$' -cpuprofile cpu.out -memprofile mem.out
> - I am calling pprof using the command
> go tool pprof sfnt.test cpu.out
> - most commands seem to work, for example:
> (pprof) top10
> Showing nodes accounting for 20130ms, 86.54% of 23260ms total
> Dropped 162 nodes (cum <= 116.30ms)
> Showing top 10 nodes out of 124
> flat flat% sum%cum cum%
> 6790ms 29.19% 29.19% 6790ms 29.19% runtime.madvise
> 4840ms 20.81% 50.00% 4840ms 20.81% syscall.syscall6
> 1910ms 8.21% 58.21% 1910ms 8.21% runtime.usleep
> 1740ms 7.48% 65.69% 1740ms 7.48% runtime.pthread_kill
> 1710ms 7.35% 73.04% 1710ms 7.35% runtime.pthread_cond_wait
> 990ms 4.26% 77.30% 990ms 4.26% runtime.kevent
> 770ms 3.31% 80.61% 2020ms 8.68%
> seehuhn.de/go/pdf/font/cff.decodeCharString
> 540ms 2.32% 82.93% 1440ms 6.19% runtime.scanobject
> 530ms 2.28% 85.21% 530ms 2.28% runtime.pthread_cond_signal
> 310ms 1.33% 86.54% 1040ms 4.47% runtime.mallocgc
> - "list" works, for example I get the expected output for list
> cff.decodeCharString
> - "weblist" does not work. If I call weblist cff.decodeCharString the
> web browser opens but shows a page containing only the following five lines
> of text, and no listing:
>
> File: sfnt.test
> Type: cpu
> Time: Jun 24, 2022 at 1:09pm (BST)
> Duration: 19.03s, Total samples = 23.26s (122.20%)
> Total: 23.26s
>
> Am I doing anything wrong? I didn't find any reports of similar problems
> on Google, so maybe this is just some oddity of my setup or me doing
> something silly?
>
> All the best,
> Jochen
>
>
--
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/789d30a8-7dd9-4826-aaef-9f25ef3494e7n%40googlegroups.com.
Re: [go-nuts] Why channel latency depends on CPU utilization?
> Your sample code above is entering the scheduler
continuously, which is not a typical characteristic of a real program
that has heavy CPU usage. It's possible that what you are seeing is
contention on the scheduler lock.
Ian,
Don't understand your point. The sample code above actually has better
latency in my test even though it is is entering the scheduler
continuously according to you:
func (c *Connection) imitateEncodeAndSend() {
onFinish := time.Now().Add(8 * time.Microsecond)
for time.Now().Before(onFinish) {
runtime.Gosched()
}
}
And this code has 10 times worse latency in my test:
func (c *Connection) imitateEncodeAndSend() {
onFinish := time.Now().Add(8 * time.Microsecond)
for time.Now().Before(onFinish) {
// runtime.Gosched()
}
}
On Monday, October 31, 2022 at 10:53:44 PM UTC+2 Ian Lance Taylor wrote:
> On Mon, Oct 31, 2022 at 1:34 PM Sergey Kurenkov
> wrote:
> >
> > I am trying to understand why higher CPU utilization leads to longer
> latency in reading from channels in golang. Could you help me with this
> question?
> >
> > I wrote a test that reads from channels and measure latency between
> writing to a channel and reading from the channel. It shows that the
> latency depends on CPU utulization. When one of functions looks like this
> >
> > func (c *Connection) imitateEncodeAndSend() {
> > onFinish := time.Now().Add(8 * time.Microsecond)
> > for time.Now().Before(onFinish) {
> > runtime.Gosched()
> > }
> > }
>
> You should make sure that you are testing CPU utilization itself,
> rather than heavy scheduler use. Sending a value on a channel
> generally requires a trip through the scheduler, to pick up the
> receiving goroutine and start running it. Often the scheduler can
> find the next job without acquiring the global scheduler lock, but not
> always. Your sample code above is entering the scheduler
> continuously, which is not a typical characteristic of a real program
> that has heavy CPU usage. It's possible that what you are seeing is
> contention on the scheduler lock.
>
> 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/7497264f-d407-423e-8b51-9567bc1fbd21n%40googlegroups.com.
Re: [go-nuts] Why channel latency depends on CPU utilization?
> Your sample code above is entering the scheduler
continuously, which is not a typical characteristic of a real program
that has heavy CPU usage. It's possible that what you are seeing is
contention on the scheduler lock.
Ian,
Don't understand your point. The sample code above actually has better
latency in my test even though it is is entering the scheduler
continuously according to you:
func (c *Connection) imitateEncodeAndSend() {
onFinish := time.Now().Add(8 * time.Microsecond)
for time.Now().Before(onFinish) {
runtime.Gosched()
}
}
And this code has 10 times worse latency in my test:
func (c *Connection) imitateEncodeAndSend() {
onFinish := time.Now().Add(8 * time.Microsecond)
for time.Now().Before(onFinish) {
// runtime.Gosched()
}
}
On Monday, October 31, 2022 at 10:53:44 PM UTC+2 Ian Lance Taylor wrote:
> On Mon, Oct 31, 2022 at 1:34 PM Sergey Kurenkov
> wrote:
> >
> > I am trying to understand why higher CPU utilization leads to longer
> latency in reading from channels in golang. Could you help me with this
> question?
> >
> > I wrote a test that reads from channels and measure latency between
> writing to a channel and reading from the channel. It shows that the
> latency depends on CPU utulization. When one of functions looks like this
> >
> > func (c *Connection) imitateEncodeAndSend() {
> > onFinish := time.Now().Add(8 * time.Microsecond)
> > for time.Now().Before(onFinish) {
> > runtime.Gosched()
> > }
> > }
>
> You should make sure that you are testing CPU utilization itself,
> rather than heavy scheduler use. Sending a value on a channel
> generally requires a trip through the scheduler, to pick up the
> receiving goroutine and start running it. Often the scheduler can
> find the next job without acquiring the global scheduler lock, but not
> always. Your sample code above is entering the scheduler
> continuously, which is not a typical characteristic of a real program
> that has heavy CPU usage. It's possible that what you are seeing is
> contention on the scheduler lock.
>
> 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/89382fae-ef6e-42b1-bc39-cfeb09df30f7n%40googlegroups.com.
[go-nuts] Why channel latency depends on CPU utilization?
I am trying to understand why higher CPU utilization leads to longer
latency in reading from channels in golang. Could you help me with this
question?
I wrote a test that reads from channels and measure latency between writing
to a channel and reading from the channel. It shows that the latency
depends on CPU utulization. When one of functions looks like this
func (c *Connection) imitateEncodeAndSend() {
onFinish := time.Now().Add(8 * time.Microsecond)
for time.Now().Before(onFinish) {
runtime.Gosched()
}
}
the average latency of reading from 5 channels is 1,5 microseconds.When
runtime.Gosched()
is commented the average latency is 10 microseconds. Why latency depends so
much on CPU utilization even though there are a lot of CPU available on the
host where I test? Could you suggest anything to improve latency when
runtime.Gosched()
is commented?
I have included the test. It has 156 LOC.
Test with not commented runtime.Gosched() :
$ N=10 C=5 go run ./multiplex.go
connections: 5, a.iterations: 10, duration: 1.352864833s, average
broadcasting latency: 720ns, average receive latency: 1.504µs, rate: 73917
Test with commented runtime.Gosched():
$ N=10 C=5 go run ./multiplex.go
connections: 5, a.iterations: 10, duration: 2.860448459s, average
broadcasting latency: 569ns, average receive latency: 10.655µs, rate: 34960
--
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/d05ca3c5-1b2f-4de5-bb0e-eea3feb27d93n%40googlegroups.com.
multiplex.go
Description: Binary data
Re: [go-nuts] Re: Makefiles for Go Programs
*** Roland Müller [2021-08-23 19:47]: >What are the alternatives to Makefile that are used by Go developers? >Please comment :-) The best thing I saw, that literally completely changed my life is DJB's redo build system. I replaced everything related to Makefile in all my projects, gaining simplicity, reliable builds, huge convenience, portability, good parallelizability and so on, so on. There are various redo's implementation and redo-inspired creations, but I have created my own, written on Go, the best one I saw from features and performance point of view: http://www.goredo.cypherpunks.ru/ https://fzakaria.com/2020/06/08/my-love-letter-to-redo.html https://apenwarr.ca/log/20101214 https://redo.readthedocs.io/en/latest/ http://jdebp.uk/FGA/introduction-to-redo.html https://habr.com/ru/post/517490/ (my post on russian) Nothing compares to its simplicity and still covering *all* Makefile's use-cases and many more. However Go takes over much work out-of-box, so there is not need to make rules for .o/.h/CFLAGS/whatever targets. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF -- 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/YSPhKXBIvjDHs%2BEi%40stargrave.org.
Re: [go-nuts] Any general VPN(pptp, l2tp, openVPN, IPSec VPN) server implementation in go?
Greetings! *** Nathan [2020-11-17 02:33]: >But I did a lot of research, it seems there is no go implementation for the >general VPN. There is pure Go ESPv3/IKEv2 implementation: http://www.gostipsec.cypherpunks.ru/ It supports small subset of algorithms, but is ok for testing purposes. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF -- 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/X7OunlgKEebbIdl8%40stargrave.org.
[go-nuts] Re: Is it acceptable to make the optional parameter as varargs
Hello Amarjeet, You can actually don't check if len(options) is greater than one – if your package provides only single implementation of Option, than there is no way to pass something different than that backoffOption. But it also brings an ability to extend your constructor later. There is a great article about optional arguments: https://sagikazarmark.hu/blog/functional-options-on-steroids/ I'd rather prefer optional arguments to builder. -- Regards, Sergey. -- 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/1e07b530-7805-4221-a6a0-61de6ca219cb%40googlegroups.com.
[go-nuts] Instrumenting in Go and code generation
Hello Gophers, I just wanted to share an article and open source tool that I've finished recently. They both are about instrumenting (aka tracing) Go components. Article covers some background on it, while tool helps to generate boilerplate code to easily provide tracing hooks in your structs. Article: https://gbws.io/articles/instrumentation-in-go/ The tool: https://github.com/gobwas/gtrace Hope it would be helpful! -- Regards, Sergey. -- 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/20200524181654.GA52504%40MacBook-Pro-Sergej.local.
[go-nuts] Why HeapInuse - HeapReleased is greater than "used" memory returned by "free" util?
Hello. I've originally asked this question on StackOverflow: https://stackoverflow.com/questions/57714300/ho-to-properly-interpret-heapinuse-heapidle-heapreleased-memory-stats-in-gol So here I will write just a quick summary: I monitor memory usage of my program to determine memory pressure conditions when I need to clean up some internal cache to prevent my program from being killed by OOM killer. The problem is that (HeapInuse - HeapReleased) value is generally in line with other system memory stats, but sometimes (after Go runtime starting to release some used memory to OS), this resulting value is greater than "used" memory reported by "free" utility: # Looks BAD: 13488 + 14 + 3631 - 489 = 16644 - more that total system memoryAvailable: 13488M, HeapAlloc: 10M, HeapInuse: 14M, HeapIdle: 3631M, HeapReleased: 489M # It is strange that at this moment HeapIdle - HeapReleased = 3142# > than 2134M of used memory reported by "free" utility. $ free totalusedfree shared buff/cache availableMem: 16123232 218569613337632 200 599904 13621988Swap: 73242180 3456073207620 But, after a while, everything is OK again: # Looks good: 11815 + 2325 + 1320 = 15460Available: 11815M, HeapAlloc: 2322M, HeapInuse: 2325M, HeapIdle: 1320M, HeapReleased: 0M I do not understand from where this additional 1.2G (16644M - 15460M) of memory comes from. When total sum is around 15,5G everything looks good and memory stats from Go and from "free" are properly aligned. But when total sum is aroung 16.6G - they aren't - as total memory size is less than that. >From where this 1.2G of memory originates? Used swap size remained the same during the whole test. Thanks in advance, Sergey. -- 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/ee7db520-e643-4ed0-a4f4-a60c783b43a4%40googlegroups.com.
Re: [go-nuts] Stack based slice usage and unsafe
Hello Ian, Thank you for your answer. On Sun, 05/26/19, May 26, 2019 at 07:59:07PM -0400, Ian Lance Taylor wrote: > This is not valid. The rule is that SliceHeader is only valid when > inspecting an actual slice header. You have to write > > h.Data = uintptr(unsafe.Pointer(&b)) > h.Len = len(b) > h.Cap = len(b) > > I assume this is reduced greatly from the real code, as you could also > just write > > bts = b[:] Does this mean that it is not possible to get rid of heap allocation for passing slice of bytes to some method interface like io.Reader.Read()? Both code examples above are leading b to escape to the heap when passing to the interface method. -- Regards, Sergey. -- 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/20190527061838.GA8345%40MacBook-Pro-Sergej.local. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Stack based slice usage and unsafe
Hi Peter,
Thank you for your answer.
Actually it is not so – please see the rule (6) of the unsafe package
documentation:
https://golang.org/pkg/unsafe/
--
Regards,
Sergey.
On Sun, 05/26/19, May 26, 2019 at 09:43:13AM -0700, peterGo wrote:
> Sergey Kamardin,
>
> Your code is invalid. A uintptr variable is an integer, not a pointer.
>
> type SliceHeader: https://golang.org/pkg/reflect/#SliceHeader
>
> SliceHeader is the runtime representation of a slice. It cannot be used
> safely or portably and its representation may change in a later release.
> Moreover, the Data field is not sufficient to guarantee the data it
> references will not be garbage collected, so programs must keep a separate,
> correctly typed pointer to the underlying data.
>
> type SliceHeader struct {
> Data uintptr
> Len int
> Cap int
> }
>
> The Go Programming Language Specification: https://golang.org/ref/spec
>
> uintptr an unsigned integer large enough to store the uninterpreted bits
> of a pointer value
>
> Peter
>
> On Sunday, May 26, 2019 at 11:30:22 AM UTC-4, Sergey Kamardin wrote:
> >
> > Hello gophers,
> >
> > I have a question which relates mostly to the ideology of unsafe usage.
> >
> > In `github.com/gobwas/ws` <http://github.com/gobwas/ws> WebSocket library
> > I used an optimization for
> > reading WebSocket frame headers into stack based slices (to reduce the
> > number of heap allocations):
> >
> > func ReadHeader(r io.Reader) (Header, error) {
> > var (
> > b [16]byte
> > bts []byte
> > )
> > h := (*reflect.SliceHeader)(unsafe.Pointer(&bts))
> > *h = reflect.SliceHeader{
> > Data: uintptr(unsafe.Pointer(&b)),
> > Len: len(b),
> > Cap: len(b),
> > }
> > _, err = io.ReadFull(r, bts)
> >
> > // process bytes and return result.
> > }
> >
> > This works fine on Linux for a long time and under the high load, but on
> > Windows it sometimes crashes or has an unexpected behaviour.
> >
> > Crashes are happened with the message like:
> > > fatal error: found bad pointer in Go heap (incorrect use of unsafe or
> > cgo?)
> >
> > I may assume that the bad pointer errors are relate to the
> > internal/poll/fd_windows.go operation buffer implementation, which
> > stores pointer to the first byte of given destination buffer – and since
> > the buffer is stack based GC throws such error.
> >
> > I may assume that the unexpected behaviour happens after goroutine stack
> > moving/copying but can not reproduce it yet during tests.
> >
> > But nevertheless, my question is: is it legal to use unsafe in that way
> > in general? Should I split the implementation of ReadHeader() to support
> > windows separately without stack based slices?
> >
> >
> > References:
> >
> > https://github.com/golang/go/blob/d97bd5d07ac4e7b342053b335428ff9c97212f9f/src/internal/poll/fd_windows.go#L526
> >
> >
> > https://github.com/gobwas/ws/blob/89d0ae05650f2cc04354d7fef282df0db5acff80/read.go#L18
> >
> > https://github.com/gobwas/ws/issues/73
> >
> >
> > --
> > Regards,
> > Sergey.
> >
>
> --
> 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/a7a2ad2d-a14d-4538-a90e-cf5a4363d467%40googlegroups.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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20190526172641.GA79977%40MacBook-Pro-Sergej.local.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Stack based slice usage and unsafe
Hello gophers,
I have a question which relates mostly to the ideology of unsafe usage.
In `github.com/gobwas/ws` WebSocket library I used an optimization for
reading WebSocket frame headers into stack based slices (to reduce the
number of heap allocations):
func ReadHeader(r io.Reader) (Header, error) {
var (
b [16]byte
bts []byte
)
h := (*reflect.SliceHeader)(unsafe.Pointer(&bts))
*h = reflect.SliceHeader{
Data: uintptr(unsafe.Pointer(&b)),
Len: len(b),
Cap: len(b),
}
_, err = io.ReadFull(r, bts)
// process bytes and return result.
}
This works fine on Linux for a long time and under the high load, but on
Windows it sometimes crashes or has an unexpected behaviour.
Crashes are happened with the message like:
> fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
I may assume that the bad pointer errors are relate to the
internal/poll/fd_windows.go operation buffer implementation, which
stores pointer to the first byte of given destination buffer – and since
the buffer is stack based GC throws such error.
I may assume that the unexpected behaviour happens after goroutine stack
moving/copying but can not reproduce it yet during tests.
But nevertheless, my question is: is it legal to use unsafe in that way
in general? Should I split the implementation of ReadHeader() to support
windows separately without stack based slices?
References:
https://github.com/golang/go/blob/d97bd5d07ac4e7b342053b335428ff9c97212f9f/src/internal/poll/fd_windows.go#L526
https://github.com/gobwas/ws/blob/89d0ae05650f2cc04354d7fef282df0db5acff80/read.go#L18
https://github.com/gobwas/ws/issues/73
--
Regards,
Sergey.
--
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/20190526152959.GA55149%40MacBook-Pro-Sergej.local.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] [PATCH] encoding/asn1: Check that ObjectIdentifier has minimal encoding
Greetings!
I think that encoding/asn1 library should be more strict with
DER-encoded objects and must check that ObjectIdentifier has minimal
encoding form: without zero-values bytes at the beginning. Here is the
simple patch to make that check.
Sorry that I am sending it here: I can not register at either Google, or
Github without JavaScript-capable browser to make contribute.html-friendly
pull-request.
-- >8 --
Subject: [PATCH] encoding/asn1: Check that ObjectIdentifier has minimal encoding
ObjectIdentifier arcs can be encoded in non-minimal form with zeros
at the beginning (0x80 ...). It is invalid DER-encoding, but BER one.
---
src/encoding/asn1/asn1.go | 4
src/encoding/asn1/asn1_test.go | 2 ++
2 files changed, 6 insertions(+)
diff --git a/src/encoding/asn1/asn1.go b/src/encoding/asn1/asn1.go
index 3cfd9d1276..8bdf9de543 100644
--- a/src/encoding/asn1/asn1.go
+++ b/src/encoding/asn1/asn1.go
@@ -313,6 +313,10 @@ func parseBase128Int(bytes []byte, initOffset int) (ret,
offset int, err error)
ret64 <<= 7
b := bytes[offset]
ret64 |= int64(b & 0x7f)
+ if offset == initOffset && ret64 == 0 {
+ err = SyntaxError{"non-minimal base 128 integer"}
+ return
+ }
offset++
if b&0x80 == 0 {
ret = int(ret64)
diff --git a/src/encoding/asn1/asn1_test.go b/src/encoding/asn1/asn1_test.go
index f0a54e0cb2..179bc894bc 100644
--- a/src/encoding/asn1/asn1_test.go
+++ b/src/encoding/asn1/asn1_test.go
@@ -237,6 +237,8 @@ var objectIdentifierTestData = []objectIdentifierTest{
{[]byte{85, 0x02, 0xc0, 0x00}, true, []int{2, 5, 2, 0x2000}},
{[]byte{0x81, 0x34, 0x03}, true, []int{2, 100, 3}},
{[]byte{85, 0x02, 0xc0, 0x80, 0x80, 0x80, 0x80}, false, []int{}},
+ {[]byte{85, 0x80, 0x01}, false, []int{}},
+ {[]byte{85, 0x01, 0x80, 0x01}, false, []int{}},
}
func TestObjectIdentifier(t *testing.T) {
--
2.18.0
--
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] Calling function with variadic arguments
Hi again,
Sorry for my previous misunderstanding. Now I realized that there no
ability in general to get the knowledge of how that slice of variadic
arguments will be used inside hidden interface method implementation.
Also, is it correct to think about variadic arguments just like about
regular slice built by compiler for us?
I mean, does compiler translates this:
```
type DoerFunc func(...int)
func caller(d DoerFunc) {
d(1, 2, 3)
}
```
To something similar:
```
type DoerFunc func([]int)
func caller(d DoerFunc) {
args := []int{1, 2, 3}
d(args)
}
```
Sergey.
--
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] Calling function with variadic arguments
Thank you for the reply. > The optimization you are talking about is escape analysis. I was trying to point not the escape analysis itself, but the ability of the compiler to construct stack-based slice for the variadic arguments instead of heap-based slices (like it does with the interfaces). I mean, seems like that there no reason to allocate slice for passing N arguments even for an interface method call? Sergey. On Mon, 11/12/18, fff Nov 12, 2018 at 10:52:07AM -0800, Ian Lance Taylor wrote: > On Mon, Nov 12, 2018 at 4:24 AM, Sergey Kamardin wrote: > > > > Also, I may assume that this because the compiler does not knows exactly > > which function it will call in a runtime. > > Most likely, yes. > > > Am I understand it right and are there any plans for preparing such > > optimizations? > > The optimization you are talking about is escape analysis. It's very > hard to do escape analysis across an interface boundary, where you > don't know what the method does. In cases involving plugins and > shared libraries, it is completely impossible to know what the method > does. I'm not aware of any plans to extend escape analysis across > calls to methods of interface values. > > It's true that in an example like yours the compiler knows the dynamic > type stored in the interface. But such examples are relatively > uncommon in Go code, so it's not clear that it's worth the extra time > required in the compiler to look for them. > > 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Calling function with variadic arguments
Hello gophers,
Does Go compiler has some optimizations for function and *method* calls
with `variadic` arguments? For example, this simple benchmark:
```
package main
import "testing"
func Do(xs ...int) (s int) {
for i, x := range xs {
s += i + x
}
return s
}
func BenchmarkDo(b *testing.B) {
for i := 0; i < b.N; i++ {
Do(i, i, i, i)
}
}
```
Provides these results:
```
BenchmarkDo-8 3 4.29 ns/op 0 B/op 0 allocs/op
```
That is, no allocation for slice of arguments is done. I may assume that
it is made by preparing `xs` slice on stack of `Do()`.
But, this example:
```
package main
import "testing"
type Doer interface {
Do(...int) int
}
type impl struct {}
func (impl) Do(xs ...int) (s int) {
for i, x := range xs {
s += i + x
}
return s
}
func BenchmarkDo(b *testing.B) {
var d Doer = impl{}
for i := 0; i < b.N; i++ {
d.Do(i, i, i, i)
}
}
```
Provides different results:
```
BenchmarkDo-8 3 25.8 ns/op 32 B/op 1 allocs/op
```
That is, I assume that this allocation is made for the slice of arguments.
Also, I may assume that this because the compiler does not knows exactly
which function it will call in a runtime.
Am I understand it right and are there any plans for preparing such
optimizations?
Regards,
Sergey.
--
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] Repeated functions with the same output in loops
> Note that calculating the length of a slice is a fast operation; it's
> a single memory load.
So, actually it just loads a slice header's field?
On Thu, 09/06/18, fff Sep 06, 2018 at 12:56:36PM -0700, Ian Lance Taylor wrote:
> On Thu, Sep 6, 2018 at 12:24 PM, mustafa katipoğlu
> <98mustafakatipo...@gmail.com> wrote:
> >
> > If I use len() function inside of a foor loop , does it calculates the
> > output each time? or if the output will be the same(like arrays) will it
> > calculates the length of the function again ?
> >
> > var letterRunes =
> > []rune("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_")
> >
> >
> > b := make([]rune, usernameLength)
> >
> >
> > for i := range b {
> >b[i] = letterRunes[rand.Intn(len(letterRunes))]
> > }
>
> It will recalculate the length each time through the loop.
>
> Note that calculating the length of a slice is a fast operation; it's
> a single memory load.
>
> 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.
> 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] WebSocket implementation in Go
Hi Gophers, I have released a stable v1.0 version of https://github.com/gobwas/ws. It implements RFC6455 and supports streaming, manual memory management and other things for writing memory efficient WebSocket applications. By the way it deals with highload in production servers for almost two years (interacting with about 3 millions connections and so on). Here is an article related to it: https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb. -- Sergey. -- 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] db interface design
> 1. there are a lot of similar functions, for example NewBook and NewAuthor.
> The difference is type of argument passed into the function. Is it a good
> idea to combine those 2 functions with a generic New(interface{}) (string,
> error) function and reflect the actual type inside?
I would not recommend to do this. Eventually logic of insertion may
become much different and your generic function's code will become a
very hard to read. Also, there is a little bit overhead on using
interfaces for non-pointer structs like `Book` and so on.
> 2. Sometimes we query based on one or more conditions (where clause), for
> example find books based on author/release data/ price. Should I create a
> generic function like:
> func FindBooks(map[string]interface{}) ([]Book, error)
It can be done in this way, but I could suggest to use some struct
`BookCriteria` with non-interface fields, say `Author string` and so on.
Then, your `FindBooks` implementation may accept that struct instance.
Or, for example, `FindBooks` may accept variadic functional options that
can fill appropriate fields of criteria. For more about functional
options you could find in Dave Cheney's article:
https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
--
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: Cgo: using syscall.Select
There are methods which are using raw file descriptors (such that https://godoc.org/github.com/mailru/easygo/netpoll#NewDesc). суббота, 19 мая 2018 г., 2:52:27 UTC+3 пользователь Juliusz Chroboczek написал: > > > You could also take a look > > at https://godoc.org/github.com/mailru/easygo/netpoll > > I don't have a net.Conn, just a raw file descriptor. > > -- Juliusz > > -- 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] how to detect in go that connection is closed without interfering into it (reading or writing data)
Hi All.
I see https://github.com/golang/go/issues/10940 issue that relates to my
problem, and it looks like I must read from / write to a connetion to check
whether it is alive, but want to ask if something get changed since this
bug was closed without a fix.
A bit of context:
I'm dialing to remote server, then "swapping sides" and establish a gRPC
listener on a client side, while remote server becomes gRPC client:
func connectAndServe(service *controlPCService) error {
conn, err := net.Dial("tcp", config.CloudURL)
if err != nil {
return err
}
err = conn.(*net.TCPConn).SetKeepAlive(true)
if err != nil {
conn.Close()
return err
}
err = conn.(*net.TCPConn).SetKeepAlivePeriod(10 * time.Second)
if err != nil {
conn.Close()
return err
}
var opts []grpc.ServerOption
grpcServer := grpc.NewServer(opts...)
service.grpcServer = grpcServer
pb.RegisterControlPCServiceServer(grpcServer, service)
grpcServer.Serve(NewListener(conn)) // it blocks
return nil
}
NewListener(conn) just returns this connection once to gRPC server, and
then blocks to emulate a situation, that there are no other connections.
The problem here, is that gRPC server still thinks that it is a server =>
after this single connection was closed by remote side, it just waits for
another one instead of exiting.
AFAIU the only thing I can do here is to listen on connection for POLLHUP
or try to read 0 bytes from it until I get EOF, but as the issue 10940
says, I can't do it. Is there any means to overcome it except of
implemening some kind of keepalive logic using gRPC calls?
Thanks in advance,
Sergey.
--
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: Can I edit/add struct tag at runtime?
Yes, you can. You can use this library: github.com/sevlyar/retag . вторник, 16 октября 2012 г., 23:38:57 UTC+7 пользователь nvcnvn написал: > > Can I edit/add struct tag at runtime? > I'm writting a simple wrap-pkg for appengine/datastore and > labix.org/v2/mgo. mgo support for dropping index by a method, since > datastore use struct tag. > If I can't edit struct tag at runtime, what is the alternative methods? > -- 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 text template - time.Format epoch
Thanks Marvin for a very comprehensive answer!
I will check it out.
On Wednesday, December 7, 2016 at 4:30:28 PM UTC+3, Sergey Krutsko wrote:
>
> Hello
>
> I have a field in my text template: "start":"{{.Start.Format "Jan 02, 2006
> 15:04:05 UTC"}}"
>
> But, I want to have output as epoch time. E.g. 148110633400
>
> Could you please explain how to do this ? 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.
Re: [go-nuts] Golang text template - time.Format epoch
Thanks Marvin!
that's exactly what i need
bwt, is there any way to get current timestamp inside the template (without
referencing to the data structure) ?
something like that:
"timestamp: {{time.Now.Unix}}"
On Wednesday, December 7, 2016 at 5:47:36 PM UTC+3, Marvin Renich wrote:
>
> * skrutsko via golang-nuts >
> [161207 08:30]:
> > Hello
> >
> > I have a field in my text template: "start":"{{.Start.Format "Jan 02,
> 2006
> > 15:04:05 UTC"}}"
> >
> > But, I want to have output as epoch time. E.g. 148110633400
> >
> > Could you please explain how to do this ? Thanks
>
> Do you mean Unix time (seconds since Jan 1, 1970 UTC)? Try
>
> "{{.Start.Unix}}"
>
> Note that in your Format above, UTC should probably be MST to print the
> time zone associated with Start. Also, I presume your code has the
> double quotes properly escaped for their context, which does not appear
> to be done above (though the context is not clear; a more complete
> example would be more helpful).
>
> ...Marvin
>
>
--
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] Can't understand the nil argument passing to function difference
Hi, I have this example:
package main
import (
"fmt"
"time"
)
func main() {
fmt.Println("Simple test")
test(nil)
fmt.Println()
fmt.Println("Base test")
var b *base
b = nil
test(b)
fmt.Println()
time.Sleep(1 * time.Second)
fmt.Println("Sub test")
var s *sub
s = nil
test(s)
}
type inter interface {
Test()
}
type base struct {
}
func (i *base) Test() {
fmt.Printf("IMPL INVOKED ON NIL %s", i)
}
type sub struct {
base
}
func test(intr inter) {
if intr != nil {
fmt.Printf("Is not nil %v\n", intr)
intr.Test()
} else {
fmt.Printf("Is nil %v NOT INVOKED ON NIL \n", intr)
}
}
And get the following result:
Simple test
Is nil NOT INVOKED ON NIL
Base test
Is not nil
IMPL INVOKED ON NIL %!s(*main.base=)
Sub test
Is not nil
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4014e5]
goroutine 1 [running]:
panic(0x4920c0, 0xc42000a0b0)
/usr/lib/go-1.7/src/runtime/panic.go:500 +0x1a1
main.(*sub).Test(0x0)
:2 +0x5
main.test(0x4f9180, 0x0)
Could anyone explain why it happens? Why nil checking is working for the
first case and doesn't work for rest of cases?
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.
