profile
viewpoint

dvyukov/go-fuzz 3548

Randomized testing for Go

google/starlark-go 1028

Starlark in Go: the Starlark configuration language, implemented in Go

dvyukov/go-fuzz-corpus 84

Corpus for github.com/dvyukov/go-fuzz examples

josharian/2015-oscon-go-perf-tutorial 19

Slides and code for Go performance tutorial given at 2015 OSCON

josharian/dont 11

Don't: template-based, decentralized static analysis for Go

josharian/compilecmp 8

automate Go compiler comparisons

josharian/countselectcases 3

Gather distribution information about select cases usage in Go (quick and dirty)

josharian/benchserve 2

benchserve turns a test binary into a benchmark server

josharian/abif 1

Package abif provides an ABIF file reader in Go

issue commentgolang/go

proposal: spec: derive array pointer from slice

@bcmills I’d love to get Filippo’s take on that. That’s not obvious to me. But it’s true that it might break existing nil pointer analysis tools, in the same way that panicking might break existing control flow analysis tools.

rogpeppe

comment created time in a day

issue commentriscv/riscv-go

Compilation of RISC-V target (CMake) is no more possible, after an update in libgo. Problems with matching arch. definition files

@prattmic this repository should probably be archived now. Want to do the honors?

advancedwebdeveloper

comment created time in 2 days

issue commentgolang/go

proposal: spec: derive array pointer from slice

I concur on choosing conversion.

I am still inclined to yield nil instead of panic. Yes, it is a bit strange, but it has nice properties.

In order to use the array value, you need to dereference, so the panic on short bounds is still there. However, avoiding the panic has better ergonomics: It is easier to check p != nil than check bounds or defer+recover.

And allowing conversions to panic could break any existing analysis tools that assume that conversions don’t alter control flow.

rogpeppe

comment created time in 4 days

issue commentgolang/go

go/doc: Display of Variables of func is ridiculous

I would ask everyone to tone down the rhetoric, please.

One possible solution is for godoc not to print function bodies. It could replace them with (say) /* body omitted */, much as unexported struct fields are omitted. (And the full contents could be shown in m=all mode, again like struct fields.)

pjebs

comment created time in 7 days

issue commentgolang/go

runtime: trim unnecessary fields from scase

As it stands, eliminating just one of these will likely help considerably, as it will make this struct SSA-able.

mdempsky

comment created time in 10 days

issue commentgolang/go

runtime: select: fatal error: index out of range

In theory this could also be caused by the libfuzzer instrumentation. cc @mdempsky just in case

prestonvanloon

comment created time in 11 days

issue commentdvyukov/go-fuzz

go-fuzz does not work with cgo

One workaround is to get the cgo/C results by executing another binary, or making an RPC call. It’s ugly, but it does work—go-fuzz has found a bunch of compiler bugs that way.

mdlayher

comment created time in 15 days

issue commentgolang/go

x/tools/gopls: complains about inconsistent vendoring in the standard library

This has been happening to me as well; it's not just @FiloSottile. I haven't dug into why, but I'd love for it to be fixed. :)

FiloSottile

comment created time in 19 days

issue closedjosharian/compilecmp

Readme: improve description on benchmark test

Regarding the number of runs, I initially thought it would only work when I specified a specific benchmark. In fact, when we specify the number of runs, all benchmarks will be run by default. This is best explained in this section.

When we do not specify the number of runs but the -all or -pkg option, the performance test does not seem to be executed ? At least I didn't see any benchmark or allocation data being printed.

We can understand these points through some exploration, but if it can be marked in the document, it should help novices to understand and use this tool faster.

closed time in 19 days

erifan

push eventjosharian/compilecmp

Josh Bleecher Snyder

commit sha c60addb97b3e0a90ac60fa06e62e6eb9f6cee47d

clarify handling of multiple runs in readme and let vscode scribble all over the document. apparently "-" is preferred to "*" for bullet points, by some mdfmt decider. Hopefully fixes #9

view details

push time in 19 days

issue commentjosharian/compilecmp

syntax error when dumping method

abb46a4520ffcaa837e3d6969427d06f4ae5b44d makes it so this now generates a better error message:

dumping SSA for (*scanner).digits:*:
cannot find package "." in:
	/Users/josh/.compilecmp/c5d7f2f1cb/src/(*scanner)

exit status 1

c3f65a5c47eb21d9c09375a61f48cca700e76bd8 fixes the problem. Those heuristics have been a perennial source of bugs. Shame on me for not having started a regression test before now.

erifan

comment created time in 19 days

push eventjosharian/compilecmp

Josh Bleecher Snyder

commit sha 12ac85659300936de5fbbe86d1f0513797e8e7da

fix dumpssa pkg/fnname split heuristic

view details

Josh Bleecher Snyder

commit sha c3f65a5c47eb21d9c09375a61f48cca700e76bd8

improve heuristic to split pkg and fnname Fixes #11

view details

push time in 19 days

issue closedjosharian/compilecmp

syntax error when dumping method

$ compilecmp -dumpssa (*scanner).digits:*
-bash: syntax error near unexpected token `('

Put the method in single or double quotes:

$ compilecmp -dumpssa '(*scanner).digits:*'
...
dumping SSA for (*scanner).digits:*:
exit status 1
panic: exit status 1

goroutine 1 [running]:
log.Panic(0xc000321858, 0x1, 0x1)
        /home/erifan01/go-in-use/src/log/log.go:351 +0xac
main.check(...)
        /home/erifan01/gopath/src/compilecmp/main.go:393
main.dumpSSA(0x0, 0x0, 0x70e8fc, 0x6, 0xc000016180, 0xa, 0xc00001a720, 0x25, 0xc000290000, 0x70e2bf, ...)
        /home/erifan01/gopath/src/compilecmp/dumpssa.go:77 +0x1293
main.comparePlatform(0x0, 0x0, 0x70e8fc, 0x6, 0x70e2bf, 0x4)
        /home/erifan01/gopath/src/compilecmp/main.go:268 +0x92c
main.compare(0x70e8fc, 0x6, 0x70e2bf, 0x4)
        /home/erifan01/gopath/src/compilecmp/main.go:196 +0x112
main.main()
        /home/erifan01/gopath/src/compilecmp/main.go:124 +0x447

But we can dump this method with: GOSSAFUNC=(*scanner).digits:* go build cmd/compile/internal/syntax

closed time in 19 days

erifan

push eventjosharian/compilecmp

Josh Bleecher Snyder

commit sha abb46a4520ffcaa837e3d6969427d06f4ae5b44d

provide better error message when dumpssa command fails

view details

push time in 19 days

startednhooyr/ctxsync

started time in 20 days

issue commentjosharian/compilecmp

syntax error when dumping method

Oh, I see. Sorry.

erifan

comment created time in 20 days

IssuesEvent

issue commentgolang/go

proposal: cmd/go: add -debug or -dwarf flag

do we know what percentage of compile time is spent on DWARF

IIRC 1–2%

versus what percentage of link time?

I don’t know this number offhand, but I think people mainly disable DWARF for smaller binaries, not faster link (or compile) times. Faster builds is an accidental benefit.

it basically has to mean a full recompilation

I’m not so sure. ‘go test’ builds without DWARF, so in the common case in which people run tests before generating a binary (both locally and in CI/CD), it might actually be the DWARF-containing build that requires significant recompilation.

If the main purpose of the flag is to be a clearer statement of intent

FWIW, a clearer statement of intent was my primary goal in filing this proposal. But as per above, I think we can also get faster builds.

josharian

comment created time in 20 days

issue closedjosharian/compilecmp

syntax error when dumping method

$ compilecmp -dumpssa (*scanner).digits:*
-bash: syntax error near unexpected token `('

Put the method in single or double quotes:

$ compilecmp -dumpssa '(*scanner).digits:*'
...
dumping SSA for (*scanner).digits:*:
exit status 1
panic: exit status 1

goroutine 1 [running]:
log.Panic(0xc000321858, 0x1, 0x1)
        /home/erifan01/go-in-use/src/log/log.go:351 +0xac
main.check(...)
        /home/erifan01/gopath/src/compilecmp/main.go:393
main.dumpSSA(0x0, 0x0, 0x70e8fc, 0x6, 0xc000016180, 0xa, 0xc00001a720, 0x25, 0xc000290000, 0x70e2bf, ...)
        /home/erifan01/gopath/src/compilecmp/dumpssa.go:77 +0x1293
main.comparePlatform(0x0, 0x0, 0x70e8fc, 0x6, 0x70e2bf, 0x4)
        /home/erifan01/gopath/src/compilecmp/main.go:268 +0x92c
main.compare(0x70e8fc, 0x6, 0x70e2bf, 0x4)
        /home/erifan01/gopath/src/compilecmp/main.go:196 +0x112
main.main()
        /home/erifan01/gopath/src/compilecmp/main.go:124 +0x447

But we can dump this method with: GOSSAFUNC=(*scanner).digits:* go build cmd/compile/internal/syntax

closed time in 20 days

erifan

issue commentjosharian/compilecmp

syntax error when dumping method

This is a matter of how the shell works; there's nothing we can do about it in compilecmp. As you said, the right fix is to put quotes around the method.

erifan

comment created time in 20 days

issue openedgolang/go

archive/tar: malformed input causes panic in parsePAXRecord

Discovered by oss-fuzz, at https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24029. This is a slightly smaller reproducer.

cc @dsnet @dvyukov @FiloSottile

Reproduce:

package main

import (
	"archive/tar"
	"bytes"
)

func main() {
	r := bytes.NewReader(data)
	t := tar.NewReader(r)
	for {
		_, err := t.Next()
		if err != nil {
			return
		}
	}
}

var data = []byte("./PaxHeaders.20745/aaa\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x000000644\x000000000\x000000000\x0000000000132\x0012531145371\x00011420\x00 x\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00ustar\x0000\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x000000000000000000000000000000000030 mtime=1432668921.098285006\n30 ctime=2147483649.151633198\n30 ctime=1432668921.151633198\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00")

Result:

$ go run fuzztar.go
panic: runtime error: slice bounds out of range [35:29]

goroutine 1 [running]:
archive/tar.parsePAXRecord(0xc0000200c0, 0x5a, 0x5a, 0x200, 0xc0000200c0, 0x5a, 0x0, 0x0, 0x0, 0x0)
	/Users/josh/go/1.14/src/archive/tar/strconv.go:269 +0x3e6
archive/tar.parsePAX(0x1106a40, 0xc000014480, 0xc0000144a8, 0x0, 0x0)
	/Users/josh/go/1.14/src/archive/tar/reader.go:310 +0x118
archive/tar.(*Reader).next(0xc000014480, 0x10d8500, 0xc00007a101, 0xc000014480)
	/Users/josh/go/1.14/src/archive/tar/reader.go:90 +0x1e2
archive/tar.(*Reader).Next(0xc000014480, 0xc000014480, 0xc000051f78, 0x1006ebf)
	/Users/josh/go/1.14/src/archive/tar/reader.go:52 +0x42
main.main()
	/Users/josh/Desktop/tardelme/fuzztar.go:12 +0x13c
exit status 2

Reproduces with tip, 1.14, and 1.13. I didn't try earlier.

created time in 22 days

issue commentspebsd/live-webrtcsignaling

license about this project

Seconded! I'd really love to poke through the code and see what I can learn. Please add a license file? Thanks.

notedit

comment created time in a month

startedpkg/json

started time in a month

issue commentgolang/go

proposal: sync: Add Mutex.LockContext

cc @bcmills who has thought about this a lot

A package that wraps up some of the channel-based approaches sounds useful, although it could live outside the standard library.

nhooyr

comment created time in a month

issue commentgolang/go

cmd/compile: reclaim binary size increase from CL 35554 constant to interface allocation optimizations

I attempted content addressability and failed, and never picked it up again. https://go-review.googlesource.com/42170

I’m not sure whether the alignment and symbol visibility changes happened. I imagine so, but cc @cherrymui just in case.

thepudds

comment created time in a month

issue commentgolang/go

cmd/go2go: build tags not supported correctly

FWIW, how go-fuzz handles this is by looking for initial comments and //go directives, saving them, manipulating the code (inserting coverage), and then re-inserting the comments. See functions initialComments and trimComments and related code in go-fuzz-build.

rogpeppe

comment created time in a month

issue commentgolang/go

proposal: io/ioutil: move Discard, NopCloser, ReadAll to io

And if we moved the remaining functions to a new package, io/fileio, we could deprecate io/ioutil entirely.

But should this happen as part of a stdlib v2? It is backwards compatible, but at the cost of a fair amount of duplication.

rsc

comment created time in a month

issue commentgolang/go

proposal: sync: Add Mutex.LockContext

Related: #27544 #6123

nhooyr

comment created time in a month

issue commentjosharian/compilecmp

Readme: improve description on benchmark test

Excellent points, thanks. Will fix.

erifan

comment created time in a month

issue commentjosharian/compilecmp

The results of dumpssa generated by compilecmp and go build are different

That really shouldn't be possible. Can you triple-check which version of Go you are running in each case? And that make.bash has been executed in each case?

erifan

comment created time in a month

issue openedgolang/go

cmd/compile: create cheapdeadcode

There are a number of places in the SSA pipeline where it would produce better code if we could run deadcode. However, deadcode is expensive.

I suspect we could create a cheaper, only slightly less effective version of deadcode:

  • Instead of building a full value liveness graph, eliminate only values that have v.Uses == 0.
  • Continue eliminating dead blocks.

One complication is line number handling, which currently depends on an ordering map which is created while building the full value liveness graph. I am not sure how best to address this; I find the existing code confusing. Perhaps @dr2chase has ideas.

We could use it in more places; we could probably also replace many uses of the full deadcode pass with it. I suspect this would end up improving both compiled code quality and compiler performance.

This is a reminder issue to investigate this. It's probably not a good introduction to the compiler, but help is definitely welcome!

created time in a month

issue commentjosharian/compilecmp

dumpssa: print out CFG by default

It’s super useful when you’re working on CFG stuff. But it gets in the way when working on other things. What I have been doing is appending the :* to the func name when I invoke it, which works. I’d be open to adding a flag for this, if you’d like, but I don’t think it should be on by default.

erifan

comment created time in a month

pull request commentpion/webrtc

Move to pion/ice@v2

May I suggest starting an “upgrading” doc explaining what people need to do to upgrade? I am happy to help copyedit it if you can get the rough material jotted down.

Sean-Der

comment created time in a month

startedfelixge/fgprof

started time in a month

pull request commentMixinNetwork/kraken

Minor fixes

@cedricfung please take another look. The new code is still significantly more performant: ~93ns/op instead of ~270ns/op, and no allocs instead of 208B/3allocs.

josharian

comment created time in a month

pull request commentMixinNetwork/kraken

Minor fixes

Sorry for the noise, Ian. I was confused about the interaction with the timer.Stop proposal.

josharian

comment created time in a month

push eventjosharian/kraken

Josh Bleecher Snyder

commit sha f1f3a790db007a09244e3a57686072f91b791311

use timer.Reset instead of creating a new Timer each iteration Fixes #2

view details

push time in a month

pull request commentMixinNetwork/kraken

Minor fixes

Huh. Good question. @ianlancetaylor, what is the preferred way to create a timer and then repeatedly kick it to some point further in the future, in performance sensitive code?

josharian

comment created time in a month

PR opened MixinNetwork/kraken

Minor fixes

Please review carefully--I am not set up to actually run these changes, and there are no tests.

(Relatedly, it'd be nicer not to check in your go.mod pion replace directives.)

+4 -3

0 comment

1 changed file

pr created time in a month

create barnchjosharian/kraken

branch : minor-fixes

created branch time in a month

fork josharian/kraken

🐙 private and efficient audio RTC network

fork in a month

issue commentMixinNetwork/kraken

performance improvement: re-use timers

For this benchmark:

package x

import (
	"testing"
	"time"
)

func BenchmarkTimerReset(b *testing.B) {
	t := time.NewTimer(time.Hour)
	defer t.Stop()
	for i := 0; i < b.N; i++ {
		t.Reset(time.Hour)
		select {
		case <-t.C:
		default:
		}
	}
}

func BenchmarkTimerStopStart(b *testing.B) {
	for i := 0; i < b.N; i++ {
		t := time.NewTimer(time.Hour)
		select {
		case <-t.C:
		default:
		}
		t.Stop()
	}
}

I get:

$ go test -bench=. -benchmem -count=5
goos: darwin
goarch: amd64
BenchmarkTimerReset-8       	13062795	        89.8 ns/op	       0 B/op	       0 allocs/op
BenchmarkTimerReset-8       	13481366	        88.5 ns/op	       0 B/op	       0 allocs/op
BenchmarkTimerReset-8       	13413853	        92.9 ns/op	       0 B/op	       0 allocs/op
BenchmarkTimerReset-8       	12489541	        88.2 ns/op	       0 B/op	       0 allocs/op
BenchmarkTimerReset-8       	13527780	        88.7 ns/op	       0 B/op	       0 allocs/op
BenchmarkTimerStopStart-8   	 4325347	       269 ns/op	     208 B/op	       3 allocs/op
BenchmarkTimerStopStart-8   	 4426946	       271 ns/op	     208 B/op	       3 allocs/op
BenchmarkTimerStopStart-8   	 4439623	       270 ns/op	     208 B/op	       3 allocs/op
BenchmarkTimerStopStart-8   	 4447804	       270 ns/op	     208 B/op	       3 allocs/op
BenchmarkTimerStopStart-8   	 4428591	       274 ns/op	     208 B/op	       3 allocs/op
PASS
josharian

comment created time in a month

issue commentMixinNetwork/kraken

suspicious comparison in engine/peer.go

I'm still learning things from reading the code, though. :) Not that I would object to docs or tests, of course.

josharian

comment created time in a month

issue commentMixinNetwork/kraken

performance improvement: re-use timers

BTW, I'm happy to send PRs for this and #1, and other things I find, but I usually make a habit of filing issues first with new projects, to make sure it's not a waste of time. :)

josharian

comment created time in a month

issue openedMixinNetwork/kraken

performance improvement: re-use timers

https://github.com/MixinNetwork/kraken/blob/221733d5bf764c9a1c6da5df61ee2937581b1dd1/engine/peer.go#L195

Given that this for loop executes on every packet, it is probably better to use NewTimer and Reset in this loop. See e.g. https://medium.com/@oboturov/golang-time-after-is-not-garbage-collected-4cbc94740082 for a bit of discussion.

created time in a month

issue openedMixinNetwork/kraken

suspicious comparison in engine/peer.go

https://github.com/MixinNetwork/kraken/blob/221733d5bf764c9a1c6da5df61ee2937581b1dd1/engine/peer.go#L336

Should this be next+uint32(gap) > 65535 instead of > 65536?

created time in a month

issue commentdpirch/libfvad

libfvad classifies any noice as a human voice.

That's my experience, too.

ababo

comment created time in a month

issue openeddpirch/libfvad

Go wrappers

I wrote a simple Go wrapper for libfvad, if you'd like to start a readme section about that. Or not. :)

created time in a month

create barnchjosharian/fvad

branch : master

created branch time in a month

created repositoryjosharian/fvad

Package fvad provides voice activity detection by wrapping libfvad.

created time in a month

pull request commentpion/webrtc

Add Track.ReadRTPContext and Track.ReadContext

pion/transport#74 abandoned due to performance impact.

josharian

comment created time in a month

pull request commentpion/srtp

Add ReadStreamSRTP.ReadContext

pion/transport#74 abandoned due to performance impact.

josharian

comment created time in a month

PR closed pion/transport

Add Buffer.ReadContext

To allow easier cancellation. This is duplicative with SetReadDeadline. The duplication is unfortunate, but contexts seem like a nicer API as you go further up the stack.

+11 -1

1 comment

1 changed file

josharian

pr closed time in a month

pull request commentpion/transport

Add Buffer.ReadContext

This has serious negative performance impact.

josharian

comment created time in a month

PR opened pion/webrtc

Add Track.ReadRTPContext and Track.ReadContext

To allow easier management of deadlines.

Depends on https://github.com/pion/transport/pull/74 and https://github.com/pion/srtp/pull/80

+17 -5

0 comment

2 changed files

pr created time in a month

PR opened pion/srtp

Add ReadStreamSRTP.ReadContext

For easier management of cancellation.

Depends on https://github.com/pion/transport/pull/74

+8 -2

0 comment

1 changed file

pr created time in a month

PR opened pion/transport

Add Buffer.ReadContext

To allow easier cancellation. This is duplicative with SetReadDeadline. The duplication is unfortunate, but contexts seem like a nicer API as you go further up the stack.

+11 -1

0 comment

1 changed file

pr created time in a month

create barnchpion/transport

branch : read-context

created branch time in a month

create barnchpion/srtp

branch : read-context

created branch time in a month

create barnchjosharian/webrtc

branch : readrtp-context

created branch time in a month

delete branch josharian/webrtc

delete branch : docs

delete time in 2 months

issue closedgolang/go

cmd/go2go

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

What did you see instead?

closed time in 2 months

josharian

issue commentgolang/go

cmd/go2go

Hit enter by accident.

josharian

comment created time in 2 months

issue openedgolang/go

cmd/go2go

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

What did you see instead?

created time in 2 months

issue commentgolang/go

runtime/pprof: TestMorestack failures aix-ppc64 builder

@aclements I was mystified as to how the likely culprit CL caused the failures in the first place, so I am probably not the right person to ask. :)

bcmills

comment created time in 2 months

issue commentgolang/go

proposal: cmd/vet: flag benchmarks that don’t use b

If we had this to do over again, it would be nice to do something more like b.RunParallel. Instead of exposing b.N, have the benchmark call b.Next() until it returns false. You could expose a Count method that returns an int for benchmarks that need to pre-size auxiliary structures. Then detecting this situation would be trivial and immediate (b.Next never got called). And we could probably do away with b.ResetTimer, since we could wait to start the timer until the first b.Next call.

But I guess that's neither here nor there.

Assuming we get CL 230978 cleaned up and submitted, anyone think we should still discuss changing cmd/vet?

It seems to me that that is an empirical question, and the relevant data point--do we still need it?--is best answered by getting CL 230978 in and then waiting to find out.

josharian

comment created time in 2 months

issue commentjosharian/intern

Running go-licenses against this repo, reports Unkown

It has a license, in license.md. GitHub found it. I guess go-license should learn to look at license.md.

chirino

comment created time in 2 months

pull request commentpion/webrtc

Overhaul the samplebuilder docs

This will fix #1242.

josharian

comment created time in 2 months

pull request commentpion/sdp

Add fuzzer

OK, the CI finally passes on this PR.

josharian

comment created time in 2 months

PR opened pion/webrtc

Overhaul the samplebuilder docs

There's one more piece I want to document, but I need some input.

What is the intended usage pattern? The obvious one is:

// create SampleBuilder sb
for  {
  //  get packet p
  sb.Push(p)
  sample := sb.Pop()
  if sample == nil {
    continue
  }
  // use sample
}

But it seems like it is theoretically possible for multiple samples to be available as a result of a single new packet (e.g. a single packet was missing a long time and then shows up). So maybe correct use is like this?

// create SampleBuilder sb
for  {
  //  get packet p
  sb.Push(p)
  for {
    sample := sb.Pop()
    if sample == nil {
      break
    }
    // use sample
  }
}

If you advise, I will document.

Also, I think the docs would benefit from mentioning typical maxLate sizes. What would you normally suggest? (Presumably different for audio and video?)

+17 -12

0 comment

1 changed file

pr created time in 2 months

push eventjosharian/webrtc

Sean DuBois

commit sha 1cbdd5f45ab2cfeb416e322fa955727a069e47ad

Fix single track PlanB offers We had an off-by-one when generating PlanB offers. Fix and add a test

view details

Guilherme

commit sha 507201e8b4960414c779b1962768bf8174b0b200

Add H264 writer Currently it only supports non-interleaved mode Therefore, only 1-23, 24 (STAP-A), 28 (FU-A) NAL types are allowed

view details

Renovate Bot

commit sha c6d54a9da2a5bd78cf4f65956ad302894ddd98f1

Update module stretchr/testify to v1.6.1 Generated by renovateBot

view details

Renovate Bot

commit sha d414278550055e77dc43f68ee704430a5bb6ab08

Update module pion/rtp to v1.5.5 Generated by renovateBot

view details

Josh Bleecher Snyder

commit sha 24877a4714b22d028592928dac0d744e827db044

Fix broken link to issue in comment Link incorrectly include /v2 to github repo

view details

Josh Bleecher Snyder

commit sha 0b117c1216cd1f0c5a7aa5bf33f8e0e60bb3b974

Document that Configurations may be re-used And simplify the existing docs.

view details

Josh Bleecher Snyder

commit sha 455e9556365f940f3df32c4254df5896be20571a

Document that some MediaEngines may be re-used And while we're here, improve a bunch of related documentation and comments.

view details

Josh Bleecher Snyder

commit sha 3627c292e73fd24f3e8e2acdbfd2eb82008f1bb3

Remove myself from contributor list I'd rather be more anonymous. Discussed here: https://gophers.slack.com/archives/CAK2124AG/p1590940118091600

view details

Renovate Bot

commit sha fb890c60a3f14bee0740c58860d3796920b04ead

Update dependency wrtc to v0.4.5 Generated by renovateBot

view details

Renovate Bot

commit sha 30f2dbd150a4530136347d33d0abfbbdaa88d892

Pin dependency request to 2.88.2 Generated by renovateBot

view details

Josh Bleecher Snyder

commit sha 59123e7d26551f5989e93de4164a47817547e0ef

Overhaul the samplebuilder docs Use complete sentences, with periods. Explain all parameters. Cross-reference other useful packages.

view details

push time in 2 months

push eventjosharian/sdp

Josh Bleecher Snyder

commit sha a9ceeeef8df2de41620193cef80e28a1364fdfb5

Add marshal and unmarshal benchmarks Use the existing fixtures.

view details

Josh Bleecher Snyder

commit sha 320f20652eec69ed2cafc4423c90f89bce79b812

Prevent trailing space on empty Address This also improves marshalling performance: name old time/op new time/op delta Marshal-8 8.04µs ± 1% 7.61µs ± 3% -5.37% (p=0.000 n=13+15) Unmarshal-8 9.13µs ± 1% 9.11µs ± 2% ~ (p=0.328 n=12+14) name old alloc/op new alloc/op delta Marshal-8 11.4kB ± 0% 11.3kB ± 0% -0.84% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 111 ± 0% 105 ± 0% -5.41% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha 0c527c613b62b89b6351a382c6b64d9c290ea41f

Allocate less during marshaling name old time/op new time/op delta Marshal-8 7.61µs ± 3% 4.23µs ± 2% -44.41% (p=0.000 n=15+14) Unmarshal-8 9.11µs ± 2% 9.44µs ± 5% ~ (p=0.783 n=14+4) name old alloc/op new alloc/op delta Marshal-8 11.3kB ± 0% 3.2kB ± 0% -71.92% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 105 ± 0% 66 ± 0% -37.14% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha 9af8e18b6e35daeeedf5b3872fbbc3210165c836

Cut unmarshal memory usage The default bufio.Reader buffer size is 4096 bytes. That's far larger than most SDPs. Size it to match the input. We could do with smaller yet, but this is simple and easy and pretty high impact. I also filed https://github.com/golang/go/issues/39332. name old time/op new time/op delta Unmarshal-8 9.44µs ± 5% 8.32µs ± 0% -11.83% (p=0.001 n=4+13) name old alloc/op new alloc/op delta Unmarshal-8 7.50kB ± 0% 4.04kB ± 0% -46.10% (p=0.000 n=4+15) name old allocs/op new allocs/op delta Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

push time in 2 months

issue openedpion/webrtc

improve samplebuilder docs

There's no indication of the units for maxLate.

It's not clear what an rtp.Depacketizer is or what a standard one might look like. What is the byte slice arg and what byte slice is it returning? The tests only show a fakeDepacketizer that is a passthrough. In my testing, a passthrough depacketizer works fine. (Should depacketizer by an option? Should it have type func instead of type interface?)

Are Push and Pop safe for concurrent use? If not, what is the intended use? (If you only Pop after Pushing, then it seems like you might lose packets unnecessarily if there is a delay in inbound packets, but maybe I misunderstand.)

created time in 2 months

issue openedpion/webrtc

document calling PeerConnection.Close, add to examples

As discussed here:

https://gophers.slack.com/archives/CAK2124AG/p1591453173401600

created time in 2 months

pull request commentpion/webrtc

Document Configuration and MediaEngine re-use

Just like https://github.com/pion/sdp/pull/52, Travis is complaining that:

it failed 'Separate subject from body with a blank line'

But I don't see any commit messages that match that description. I really want to want to contribute to pion, but the constant battles with the linter are pretty frustrating and time consuming.

josharian

comment created time in 2 months

pull request commentpion/sdp

Add fuzzer

Travis failed this PR, saying:

it failed 'Separate subject from body with a blank line'

But I don't see that any of my commit messages match this description. (And, unhelpfully, it doesn't appear to tell me which commit message is the problem.) I extracted the test it is doing (awk 'NR == 2 {print $1;}' | wc -c != 1 and ran it on each commit in turn, and they all passed.

Any hints?

I've now spent more time trying to fix lint complaints (spelling, commit messages, where to write my name) than actually working on the code.

josharian

comment created time in 2 months

push eventjosharian/sdp

Josh Bleecher Snyder

commit sha 484b472196df035893b4f053e6e41da8bcab1572

Remove myself from contributor list requirement I'd rather be more anonymous. Discussed here: https://gophers.slack.com/archives/CAK2124AG/p1590940118091600

view details

Josh Bleecher Snyder

commit sha d3bb5a7cc3cf90c56648703cb478a6904b0e8408

Always use a non-nil Address during unmarshal Right now, attempting to unmarshal an SDP and then marshal the results can cause a panic. Fix that by ensuring we always create a non-nil Address.

view details

Max Hawkins

commit sha 7205fbc59532bb2021276191034e6cebf6244aab

Add fuzzer This will help us find parse errors not covered by our tests.

view details

Josh Bleecher Snyder

commit sha ba96b979874846433041f4bb5ede99b36d668650

Add marshal and unmarshal benchmarks

view details

Josh Bleecher Snyder

commit sha f89d50deea9771ca5f1497ee5b884cffc75c629c

Prevent trailing space on empty Address This also improves marshalling performance: name old time/op new time/op delta Marshal-8 8.04µs ± 1% 7.61µs ± 3% -5.37% (p=0.000 n=13+15) Unmarshal-8 9.13µs ± 1% 9.11µs ± 2% ~ (p=0.328 n=12+14) name old alloc/op new alloc/op delta Marshal-8 11.4kB ± 0% 11.3kB ± 0% -0.84% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 111 ± 0% 105 ± 0% -5.41% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha 8d225290b757d4856f97de5ce8bca52e2f0628db

Allocate less during marshaling name old time/op new time/op delta Marshal-8 7.61µs ± 3% 4.23µs ± 2% -44.41% (p=0.000 n=15+14) Unmarshal-8 9.11µs ± 2% 9.44µs ± 5% ~ (p=0.783 n=14+4) name old alloc/op new alloc/op delta Marshal-8 11.3kB ± 0% 3.2kB ± 0% -71.92% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 105 ± 0% 66 ± 0% -37.14% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha 9c5b6fd7e62b581b955761dc7d1cc6081af323e7

Cut unmarshal memory usage The default bufio.Reader buffer size is 4096 bytes. That's far larger than most SDPs. Size it to match the input. We could do with smaller yet, but this is simple and easy and pretty high impact. I also filed https://github.com/golang/go/issues/39332. name old time/op new time/op delta Unmarshal-8 9.44µs ± 5% 8.32µs ± 0% -11.83% (p=0.001 n=4+13) name old alloc/op new alloc/op delta Unmarshal-8 7.50kB ± 0% 4.04kB ± 0% -46.10% (p=0.000 n=4+15) name old allocs/op new allocs/op delta Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

push time in 2 months

push eventjosharian/webrtc

Renovate Bot

commit sha 7b37f0f77ffb71dfc8be5c4944063680998ee538

Update module pion/rtcp to v1.2.3 Generated by renovateBot

view details

salmān aljammāz

commit sha 7a95bb893a5e06a778258af937d755c4a89f0ee7

WASM: Fallback to SDP line for candiate callback On Firefox, the RTCIceCandidate interface appears to just be an RTCIceCandidateInit in disguise. That is, it does not have properties for each individual component of the candidate line. It only has the raw SDP string in the candidate property. This change falls back to parsing the candidate line if some expected property is missing when preparing the candidate for the callback OnICECandidate. https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate https://caniuse.com/#feat=mdn-api_rtcicecandidate_priority

view details

salmān aljammāz

commit sha 461892201168299a5254a5ae803369bfacec337f

Implement js.Wrapper interface for PeerConnection This allows us to extract the RTCPeerConnection object and pass it back to JavaScript land. It is useful for building applications where some parts (e.g. signalling) are written in Go and others (e.g. media or datachannel handling) are in JavaScript.

view details

cnderrauber

commit sha 667941621dd8c895a5dd23b133e1913221b0cf7e

RtpSender/Receiver.Read return err when stopped Rtpsender.Read & RtpReceiver.Read may block infinite when it's stopped before Send/Receive has been called.

view details

Renovate Bot

commit sha 1993085670eb9ab7c2e6cf92b482b193050b2ad8

Update module stretchr/testify to v1.6.0 Generated by renovateBot

view details

Renovate Bot

commit sha 7cf85a8d3e0e8a0220f8afc53186ee8240093f87

Update module pion/srtp to v1.3.4 Generated by renovateBot

view details

Josh Bleecher Snyder

commit sha e42bb3e27a8b101cf1ec5cd2fd21a41da3a6dada

Use exported errors for stopped rtp i/o This makes checking for these errors much more robust than doing a string comparison.

view details

Renovate Bot

commit sha 68825977a0f473d3bbc9b1134ee5227cacce4ee5

Update module pion/sdp/v2 to v2.3.8 Generated by renovateBot

view details

Juliusz Chroboczek

commit sha 9bbffdd5aab2f271629aef6b912190d0de358d6e

Simplify operations Operations is now essentially a slice protected by a single lock. No lock is held during execution, serialisation is guaranteed by ensuring that there is at most one goroutine running at a time. A coincidental benefit is that we now won't deadlock if an operation panics. While this should be slightly faster, the main point of this change is to reduce the amount of noise in the blocking profile.

view details

Josh Bleecher Snyder

commit sha 36b1345db1b936cc8612ddfe9b3a7a1b7af736c8

Fix broken link to issue in comment

view details

Josh Bleecher Snyder

commit sha 02fca013acecca2c1b337d0c3db99b7785a54169

Document that Configurations may be re-used And simplify the existing docs.

view details

Josh Bleecher Snyder

commit sha 68b207cc3b5cd21d4836b2e0cce6262e4c43cf12

Document that some MediaEngines may be re-used And while we're here, improve a bunch of related documentation and comments.

view details

Josh Bleecher Snyder

commit sha 841dc260d42333adc39606528de832979c0ced8e

Remove myself from contributor list I'd rather be more anonymous. Discussed here: https://gophers.slack.com/archives/CAK2124AG/p1590940118091600

view details

push time in 2 months

issue openedpion/webrtc

reading from a track too early causes a panic

If you create a track and then immediately call Read on it, you get this panic:

goroutine 10 [running]:
github.com/pion/webrtc/v2.(*RTPReceiver).readRTP(0x0, 0xc0001e2580, 0x578, 0x578, 0x0, 0x62, 0xc0000fca90)
	/Users/josh/pkg/mod/github.com/pion/webrtc/v2@v2.2.15-0.20200606101323-d41427855005/rtpreceiver.go:163 +0x26
github.com/pion/webrtc/v2.(*Track).Read(0xc000118120, 0xc0001e2580, 0x578, 0x578, 0x2, 0x62, 0x0)
	/Users/josh/pkg/mod/github.com/pion/webrtc/v2@v2.2.15-0.20200606101323-d41427855005/track.go:97 +0xf1

The relevant code is:

func (t *Track) Read(b []byte) (n int, err error) {
	t.mu.RLock()
	if len(t.activeSenders) != 0 {
		t.mu.RUnlock()
		return 0, fmt.Errorf("this is a local track and must not be read from")
	}
	r := t.receiver
	t.mu.RUnlock()

	return r.readRTP(b)
}

I think we should check r != nil before calling r.readRTRP, and if nil, return an error.

created time in 2 months

issue commentgolang/go

cmd/compile: struct equality code optimization

Thanks. I’m still AFK but I suspect (purely from the issue text) that it’d be easier/better to fix this by strengthening the shortcircuit pass more.

randall77

comment created time in 2 months

issue closedgolang/go

bufio: set default buffer size from *bytes.Reader

I just came across some code that does this rather natural thing:

r := bufio.NewReader(bytes.NewReader(buf))
//  use r to do bufio-ish things

However, len(buf) is typically low, much smaller than the default buffer size of 4096. I think that bufio.NewReader should check whether r is a *bytes.Reader, and if so, use r.Len() to size the buffer (assuming r.Len() is less than 4096).

Implementation is easy, and would be a good first contribution for someone.

Any objections?

cc @griesemer @bradfitz @ianlancetaylor per golang.org/s/owners

closed time in 2 months

josharian

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

Sounds like the consensus is that this isn’t possibly to do now in a way that is simple and uniformly helpful.

josharian

comment created time in 2 months

issue commentgolang/go

proposal: spec: decide ambiguity in comparing array/structs with interface fields/elements

OK. Are you using structs with > 4 fields? That might be necessary, since we inline “small” comparisons, and that goes through a different code generation path. (I recently filed an issue to unify them, but can’t find it on my phone.)

mdempsky

comment created time in 2 months

issue commentgolang/go

proposal: spec: decide ambiguity in comparing array/structs with interface fields/elements

Thanks, Keith.

Acutally, Josh, I don't think CL 230207 needed to be reverted.

I’m still AFK, but I think they make equivalent changes to algs for

type T struct { a, b, c, d, e interface{} }

as to

type T [5]interface{}

mdempsky

comment created time in 2 months

issue commentgolang/go

proposal: spec: decide ambiguity in comparing array/structs with interface fields/elements

We should probably revert CLs 230207 and 230208, and re-attempt them (or a modified version of them) if appropriate for 1.16. I am AFK and will be for a few days, and the beta is soon (I hope). Any chance someone would do the reverts for me? Thanks.

mdempsky

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

FWIW, I came across it in real code by profiling an actual server.

josharian

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

@bcmills I’m still pondering.

I wonder whether we should track whether we auto-sizes the buffer originally and be prepared to switch to a large buffer if needed during Reset. Then we potentially have two allocations instead of one, but at most two. That’s for the “use Len” approach.

For the more invasive, “re-use the existing buffer” approach, i think it is clearer what to do in Reset—if we are working with a borrowed buffer, switch to a new borrowed buffer (or allocate a new one if there isn’t one to borrow).

If that’s all too clever, maybe we should just address this with documentation. (And a staticcheck check? cc @dominikh )

josharian

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

Adding new API requires opening a new proposal issue first. Feel free to do that!

josharian

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

@bcmills oops, indeed. Thanks.

josharian

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

@bradford-hamilton I say go for it. I’d be tempted to do two CLs, first only using Len, then sharing the underlying buffer, so that we can roll back the second one independently if needed.

@bradfitz instead of WriteTo, seems like just Bytes would do it. What am I missing?

@bcmills yeah, I wish we could use a method, and we probably could have long ago. Probably not now, sadly.

josharian

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

@qingyunha i don’t think there’s a bufio->strings dependency yet, and I’d be reluctant to add one.

josharian

comment created time in 2 months

issue commentgolang/go

bufio: set default buffer size from *bytes.Reader

In theory yes but I worry about Hyrum’s Law and people modifying the buffer underfoot. Maybe we should start there early in cycle and fall back to the less aggressive optimization if needed.

josharian

comment created time in 2 months

push eventjosharian/sdp

Josh Bleecher Snyder

commit sha 0c8974b8b241a994ce7ce9fcf73f3590df6f5e9c

Allocate less during marshaling name old time/op new time/op delta Marshal-8 7.61µs ± 3% 4.23µs ± 2% -44.41% (p=0.000 n=15+14) Unmarshal-8 9.11µs ± 2% 9.44µs ± 5% ~ (p=0.783 n=14+4) name old alloc/op new alloc/op delta Marshal-8 11.3kB ± 0% 3.2kB ± 0% -71.92% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 105 ± 0% 66 ± 0% -37.14% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha d0733c1bc646a8d68d56b4d23338c5c3a8421778

Cut unmarshal memory usage The default bufio.Reader buffer size is 4096 bytes. That's far larger than most SDPs. Size it to match the input. We could do with smaller yet, but this is simple and easy and pretty high impact. I also filed https://github.com/golang/go/issues/39332. name old time/op new time/op delta Unmarshal-8 9.44µs ± 5% 8.32µs ± 0% -11.83% (p=0.001 n=4+13) name old alloc/op new alloc/op delta Unmarshal-8 7.50kB ± 0% 4.04kB ± 0% -46.10% (p=0.000 n=4+15) name old allocs/op new allocs/op delta Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

push time in 2 months

pull request commentpion/sdp

Add fuzzer

The build failure is because it claims that "marshalling" is the wrong spelling.

https://stackoverflow.com/questions/4434590/marshall-or-marshal-marshalling-or-marshaling

The wikipedia entry contains both spellings: https://en.wikipedia.org/wiki/Marshalling_(computer_science)

I will change it, but under protest.

josharian

comment created time in 2 months

pull request commentpion/sdp

Add fuzzer

I've added my name to the readme, although I'm not happy about it. I'll raise that on slack.

I've also added some performance optimizations. There's plenty more low hanging fruit after this, but it is a start.

josharian

comment created time in 2 months

push eventjosharian/sdp

Renovate Bot

commit sha 9a8f39fd9db576ac6799d2174c278cb773edd4b3

Update module stretchr/testify to v1.6.0 Generated by renovateBot

view details

Josh Bleecher Snyder

commit sha e1bea87b3f83fec25266ca81f604a099f38a2312

Add myself to the README

view details

Josh Bleecher Snyder

commit sha 514a8985639f881eea6c03bdf95fa095010991c2

Always use a non-nil Address during unmarshal Right now, attempting to unmarshal an SDP and then marshal the results can cause a panic. Fix that by ensuring we always create a non-nil Address.

view details

Max Hawkins

commit sha be5c0ba8ec584c21438ba1b6e572c7ae5469df2f

Add fuzzer This will help us find parse errors not covered by our tests.

view details

Josh Bleecher Snyder

commit sha 85afea2c56068adf1134b4d9a8f88e822926d623

Add marshal and unmarshal benchmarks

view details

Josh Bleecher Snyder

commit sha 3f5a9aff14d3c4bb804c2289ab2378d459193c3e

Prevent trailing space on empty Address This also improves marshalling performance: name old time/op new time/op delta Marshal-8 8.04µs ± 1% 7.61µs ± 3% -5.37% (p=0.000 n=13+15) Unmarshal-8 9.13µs ± 1% 9.11µs ± 2% ~ (p=0.328 n=12+14) name old alloc/op new alloc/op delta Marshal-8 11.4kB ± 0% 11.3kB ± 0% -0.84% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 111 ± 0% 105 ± 0% -5.41% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha fd219748610120ba3fcadbaa813f44a8c733b080

Allocate less during marshalling name old time/op new time/op delta Marshal-8 7.61µs ± 3% 4.23µs ± 2% -44.41% (p=0.000 n=15+14) Unmarshal-8 9.11µs ± 2% 9.44µs ± 5% ~ (p=0.783 n=14+4) name old alloc/op new alloc/op delta Marshal-8 11.3kB ± 0% 3.2kB ± 0% -71.92% (p=0.000 n=15+15) Unmarshal-8 7.50kB ± 0% 7.50kB ± 0% ~ (all equal) name old allocs/op new allocs/op delta Marshal-8 105 ± 0% 66 ± 0% -37.14% (p=0.000 n=15+15) Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

Josh Bleecher Snyder

commit sha d2ae39461afafbcbf83d7b9fb161898ccdc82652

Cut unmarshal memory usage The default bufio.Reader buffer size is 4096 bytes. That's far larger than most SDPs. Size it to match the input. We could do with smaller yet, but this is simple and easy and pretty high impact. I also filed https://github.com/golang/go/issues/39332. name old time/op new time/op delta Unmarshal-8 9.44µs ± 5% 8.32µs ± 0% -11.83% (p=0.001 n=4+13) name old alloc/op new alloc/op delta Unmarshal-8 7.50kB ± 0% 4.04kB ± 0% -46.10% (p=0.000 n=4+15) name old allocs/op new allocs/op delta Unmarshal-8 133 ± 0% 133 ± 0% ~ (all equal)

view details

push time in 2 months

Pull request review commentpion/sdp

Add fuzzer

 func unmarshalConnectionInformation(value string) (*ConnectionInformation, error 		return nil, fmt.Errorf("sdp: invalid value `%v`", fields[1]) 	} -	var connAddr *Address+	connAddr := new(Address)

This is not due to this change; it is because of how ConnectionInformation.String is generated. I've added a commit to this PR to fix it, though.

josharian

comment created time in 2 months

issue openedgolang/go

bufio: set default buffer size from *bytes.Reader

I just came across some code that does this rather natural thing:

r := bufio.NewReader(bytes.NewReader(buf))
//  use r to do bufio-ish things

However, len(buf) is typically low, much smaller than the default buffer size of 4096. I think that bufio.NewReader should check whether r is a *bytes.Reader, and if so, use r.Len() to size the buffer.

Implementation is easy, and would be a good first contribution for someone.

Any objections?

cc @griesemer @bradfitz @ianlancetaylor per golang.org/s/owners

created time in 2 months

pull request commentpion/webrtc

use exported errors for reads/writes to stopped rtp i/o

Done.

josharian

comment created time in 2 months

push eventjosharian/webrtc

Josh Bleecher Snyder

commit sha 99e3145e0fe50e355bf1db028227f3b4269cfeaa

Use exported errors for stopped rtp i/o This makes checking for these errors much more robust than doing a string comparison.

view details

push time in 2 months

more