2 Commits (dsnet/jsonimports-ci)

Author	SHA1	Message	Date
Joe Tsai	c299a96624	all: apply consistent imports of "json" packages ... This runs: go run ./cmd/jsonimports -update -ignore=tempfork/ which applies the following rules: * Until the Go standard library formally accepts "encoding/json/v2" and "encoding/json/jsontext" into the standard library (i.e., they are no longer considered experimental), we forbid any code from directly importing those packages. Go code should instead import "github.com/go-json-experiment/json" and "github.com/go-json-experiment/json/jsontext". The latter packages contain aliases to the standard library if built on Go 1.25 with the goexperiment.jsonv2 tag specified. * Imports of "encoding/json" or "github.com/go-json-experiment/json/v1" must be explicitly imported under the package name "jsonv1". If both packages need to be imported, then the former should be imported under the package name "jsonv1std". * Imports of "github.com/go-json-experiment/json" must be explicitly imported under the package name "jsonv2". The latter two rules exist to provide clarity when reading code. Without them, it is unclear whether "json.Marshal" refers to v1 or v2. With them, however, it is clear that "jsonv1.Marshal" is calling v1 and that "jsonv2.Marshal" is calling v2. Updates tailscale/corp#791 Signed-off-by: Joe Tsai <joetsai@digital-static.net>	1 month ago
James Tucker	e8f1721147	syncs: add ShardedInt expvar.Var type ... ShardedInt provides an int type expvar.Var that supports more efficient writes at high frequencies (one order of magnigude on an M1 Max, much more on NUMA systems). There are two implementations of ShardValue, one that abuses sync.Pool that will work on current public Go versions, and one that takes a dependency on a runtime.TailscaleP function exposed in Tailscale's Go fork. The sync.Pool variant has about 10x the throughput of a single atomic integer on an M1 Max, and the runtime.TailscaleP variant is about 10x faster than the sync.Pool variant. Neither variant have perfect distribution, or perfectly always avoid cross-CPU sharing, as there is no locking or affinity to ensure that the time of yield is on the same core as the time of core biasing, but in the average case the distributions are enough to provide substantially better performance. See golang/go#18802 for a related upstream proposal. Updates tailscale/go#109 Updates tailscale/corp#25450 Signed-off-by: James Tucker <james@tailscale.com>	12 months ago