From https://github.com/golang/go/issues/43930
> SwissTable: Google3 may want to do some benchmarking on this. Maps are used heavily in google3. This may be of value to us.
There is a chance that next #golang releases will have a faster map implementation!
(Note: Google3 is Google's monorepo)
> SwissTable: Google3 may want to do some benchmarking on this. Maps are used heavily in google3. This may be of value to us.
There is a chance that next #golang releases will have a faster map implementation!
(Note: Google3 is Google's monorepo)
GitHub
Go compiler and runtime meeting notes · Issue #43930 · golang/go
Google's Go compiler and runtime team meets periodically (roughly weekly) to discuss ongoing development of the compiler and runtime. While not open to the public, there's been desire by th...
#golang linker optimisation in upcoming Go 1.21 https://go-review.googlesource.com/c/go/+/490915
(There is even more changes, see drop from Apr 24)
(There is even more changes, see drop from Apr 24)
Felix Geisendörfer:
Interesting proposal from Russ Cox to improve the accuracy of the mutex profiler in #golang.
If you hold a mutex for 10ms and 5 goroutines wait for 10ms each, only 10ms of contention are recorded. The proposal is to change this to 50ms 👍🏻
https://github.com/golang/go/issues/61015
Interesting proposal from Russ Cox to improve the accuracy of the mutex profiler in #golang.
If you hold a mutex for 10ms and 5 goroutines wait for 10ms each, only 10ms of contention are recorded. The proposal is to change this to 50ms 👍🏻
https://github.com/golang/go/issues/61015
Waiting for go1.21: Execution Tracing with < 1% Overhead
https://blog.felixge.de/waiting-for-go1-21-execution-tracing-with-less-than-one-percent-overhead/
https://blog.felixge.de/waiting-for-go1-21-execution-tracing-with-less-than-one-percent-overhead/
Felix Geisendörfer
Waiting for go1.21: Execution Tracing with < 1% Overhead
Learn about the upcoming go1.21 performance improvements that reduce the overhead of execution tracing from up to 20% to less than 1% for most applications.
Analyzing #golang Build Times https://blog.howardjohn.info/posts/go-build-times/
blog.howardjohn.info
Analyzing Go Build Times
Go is often praised for its fast build times.
While they are pretty quick, they are slow enough that I spend a lot of time waiting for them, enough that it prompted me to go down the rabbit hole of thoroughly analyzing them.
This post covers all aspects of…
While they are pretty quick, they are slow enough that I spend a lot of time waiting for them, enough that it prompted me to go down the rabbit hole of thoroughly analyzing them.
This post covers all aspects of…
Great initiative! Improvements to the #golang inliner https://github.com/golang/go/issues/61502
Design doc https://docs.google.com/document/d/1a6p7-nbk5PVyM1S2tmccFrrIuGzCyzclstBtaciHxVw
Design doc https://docs.google.com/document/d/1a6p7-nbk5PVyM1S2tmccFrrIuGzCyzclstBtaciHxVw
GitHub
cmd/compile: overhaul inliner · Issue #61502 · golang/go
We’re starting a project to overhaul the inlining optimization pass in the Go compiler, with the goal of having a far more effective inliner in Go 1.22. This issue will track this work. This docume...
#golang proposal: time: stop requiring Timer/Ticker.Stop for prompt GC
https://github.com/golang/go/issues/61542 (almost a decade from the original https://github.com/golang/go/issues/8898 CC: @dvyukov )
https://github.com/golang/go/issues/61542 (almost a decade from the original https://github.com/golang/go/issues/8898 CC: @dvyukov )
GitHub
time: stop requiring Timer/Ticker.Stop for prompt GC · Issue #61542 · golang/go
After almost a decade, I have finally implemented #8898, special-casing the channels used for timers (or maybe the timers used for channels) so that the timers are not in the timer heap when there ...
Common pitfalls in Go benchmarking
https://eli.thegreenplace.net/2023/common-pitfalls-in-go-benchmarking/
By @elibendersky
https://eli.thegreenplace.net/2023/common-pitfalls-in-go-benchmarking/
By @elibendersky
🇺🇦 Go performance channel
From @hackernews https://news.ycombinator.com/item?id=37054760
By the way, from release notes
> Go 1.21 improves build speed by up to 6%, largely thanks to building the compiler itself with PGO.
> Go 1.21 improves build speed by up to 6%, largely thanks to building the compiler itself with PGO.
Every nanosecond matter.
Restructuring code to win 15-20ns in time.Since: https://go-review.googlesource.com/c/go/+/518336
Remove your „//go:linkname runtime.nanotime1” after #golang 1.22 :D
Restructuring code to win 15-20ns in time.Since: https://go-review.googlesource.com/c/go/+/518336
Remove your „//go:linkname runtime.nanotime1” after #golang 1.22 :D
C and C++ Prioritize Performance over Correctness
https://research.swtch.com/ub
https://research.swtch.com/ub
Redesign #golang PCDATA encoding
> format that's >4x faster to decode than the Go 1.21 tables, while increasing binary size by only 1–2.5%.
https://github.com/golang/go/issues/61984
> format that's >4x faster to decode than the Go 1.21 tables, while increasing binary size by only 1–2.5%.
https://github.com/golang/go/issues/61984
GitHub
runtime,cmd/compile: redesign PCDATA encoding · Issue #61984 · golang/go
I've been experimenting with alternate encodings for the PCDATA tables, with the goal of significantly improving decode speed, at possibly a slight increase in binary size. @mknyszek, @dr2chase...
proposal: encoding: add AppendText and AppendBinary #golang
https://github.com/golang/go/issues/62384
https://github.com/golang/go/issues/62384
GitHub
encoding: add AppendText and AppendBinary · Issue #62384 · golang/go
The MarshalText and MarshalBinary methods are a trash factory. They create a short-lived string that is almost always garbage collectable shortly after creation. Furthermore, the caller almost alwa...
❤2