High Performance Go Workshop by twitter.com/davecheney
Great page for an intro to achieve faster #golang code and also a good source of best practices.
https://dave.cheney.net/high-performance-go-workshop/dotgo-paris.html
Great page for an intro to achieve faster #golang code and also a good source of best practices.
https://dave.cheney.net/high-performance-go-workshop/dotgo-paris.html
Reducing Memory Allocations in #golang
https://chris124567.github.io/2021-06-21-go-performance/
by https://github.com/chris124567
https://chris124567.github.io/2021-06-21-go-performance/
by https://github.com/chris124567
chris124567.github.io
Reducing Memory Allocations in Golang
Go’s place between C and Python in terms of abstraction and garbage collection memory management model has made it attractive to programmers looking for a fast but reasonably high level language. However, there is no free lunch. Go’s abstractions, especially…
#golang 1.17 RC1 is amazing.
This service does a lot of JSON operations, math and too many loops :D
Also reflection, outside of encoding/json.
(Screenshot by a friend of mine.)
https://twitter.com/golang/status/1415045781233545218
This service does a lot of JSON operations, math and too many loops :D
Also reflection, outside of encoding/json.
(Screenshot by a friend of mine.)
https://twitter.com/golang/status/1415045781233545218
🇺🇦 Go performance channel
#golang 1.17 RC1 is amazing. This service does a lot of JSON operations, math and too many loops :D Also reflection, outside of encoding/json. (Screenshot by a friend of mine.) https://twitter.com/golang/status/1415045781233545218
Clarification: middle of the graph is 1.17 RC1
Graph show: 1.16 -> 1.17 RC1 -> (rollback to) 1.16
Prometheus query:
Graph show: 1.16 -> 1.17 RC1 -> (rollback to) 1.16
Prometheus query:
irate(process_cpu_seconds_total{kubernetes_pod_name=~"$kubernetes_pod_name"}[1m])
🤞 for the new JSON pkg in #golang https://github.com/go-json-experiment/json
Also take a look how to use new fuzzing (which will not appear in 1.17 😢) https://github.com/go-json-experiment/json/blob/master/fuzz_test.go
Also take a look how to use new fuzzing (which will not appear in 1.17 😢) https://github.com/go-json-experiment/json/blob/master/fuzz_test.go
GitHub
GitHub - go-json-experiment/json: Experimental implementation of a proposed v2 encoding/json package
Experimental implementation of a proposed v2 encoding/json package - go-json-experiment/json
#golang optimisations by @ShiftLeftInc
https://blog.shiftleft.io/an-optimisation-story-building-a-code-scanner-for-large-golang-apps-efabd17258ea
https://blog.shiftleft.io/an-optimisation-story-building-a-code-scanner-for-large-golang-apps-efabd17258ea
Medium
An Optimisation Story: Building a Code Scanner for Large Golang Apps
This post will shed some light on how we were able to optimise one of our frontends, reducing the typical project’s run time by half…
Not a performance oriented tweet, but you can play with #golang generics in 1.17 via "-gcflags=-G=3"
https://github.com/mattn/go-generics-example thanks @mattn_jp
https://github.com/mattn/go-generics-example thanks @mattn_jp
GitHub
GitHub - mattn/go-generics-example: Example code for Go generics
Example code for Go generics. Contribute to mattn/go-generics-example development by creating an account on GitHub.
Generics are slowly eating #golang. Jokes aside. This is a good things which will reduce a bit of boilerplate.
https://github.com/golang/go/issues/47657
https://github.com/golang/go/issues/47657
GitHub
proposal: sync, sync/atomic: add PoolOf, MapOf, ValueOf · Issue #47657 · golang/go
This proposal is for use with #43651. We propose using type parameters to add compile-time-type-safe variants of sync.Pool, sync.Map, and atomic.Value. This proposal is not targeted for any specifi...
🇺🇦 Go performance channel
https://twitter.com/go_perf/status/1428616422398234626
Twitter
Josh Bleecher Snyder
I hacked up a simple way to assert that a Go value is immutable. It's pretty raw and certainly has bugs, but it appears to work: github.com/tailscale/go/p… (And big hat tip and thank you to @Tailscale, where amazingly enough this was part of my day job today.)
Old but very-very good file read-parsing optimisation in #golang by @marcellanz
https://marcellanz.com/post/file-read-challenge/
https://marcellanz.com/post/file-read-challenge/
Proposal: Soft memory limit
<...>
- Better utilize the memory that they already have,
- Confidently decrease their memory limits, knowing #golang will respect them,
- Avoid unsupported forms of garbage collection tuning.
https://github.com/golang/go/issues/48409
<...>
- Better utilize the memory that they already have,
- Confidently decrease their memory limits, knowing #golang will respect them,
- Avoid unsupported forms of garbage collection tuning.
https://github.com/golang/go/issues/48409
GitHub
runtime/debug: soft memory limit · Issue #48409 · golang/go
Proposal: Soft memory limit Author: Michael Knyszek Summary I propose a new option for tuning the behavior of the Go garbage collector by setting a soft memory limit on the total amount of memory t...
🇺🇦 Go performance channel
https://twitter.com/go_perf/status/1438933426946588678
Twitter
Ignacio Hagopian
Two low-hanging fruit optimizations in strings.Replace that allows double-digit speedup and memory saving in the existing reference benchmark. #golang #performance go-review.googlesource.com/c/go/+/343089
A 5x reduction in RAM usage with Zoekt memory
optimizations #golang by @sourcegraph
Cut 64-bit ngrams in two is an interesting trick but not so many places where you can apply it.
https://about.sourcegraph.com/blog/zoekt-memory-optimizations-for-sourcegraph-cloud/
optimizations #golang by @sourcegraph
Cut 64-bit ngrams in two is an interesting trick but not so many places where you can apply it.
https://about.sourcegraph.com/blog/zoekt-memory-optimizations-for-sourcegraph-cloud/
Sourcegraph
A 5x reduction in RAM usage with Zoekt memory optimizations
Here’s how we went from using 1400KB of RAM per repo to just 310KB without affecting latency.
There was an issue with a heavy #golang contexts (more than 12 or even 50) because iteration over context was done recursively.
https://github.com/golang/go/issues/47292
The good news it's fixed via iterative approach https://github.com/golang/go/commit/afe43f1e5e0d256341689195454527726b26ccae
The problem is rare but better not to have it at all.
https://github.com/golang/go/issues/47292
The good news it's fixed via iterative approach https://github.com/golang/go/commit/afe43f1e5e0d256341689195454527726b26ccae
The problem is rare but better not to have it at all.
GitHub
context: recursive implementation of Context.Value triggers stack resize · Issue #47292 · golang/go
As discussed in #33283, Go's implementation or valueCtx.Value is recursive which means that the cost grows linearly with the depth of the context chain. But one issue not discussed there is tha...