-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proto: disable XXX_NoUnkeyedLiteral and XXX_sizecache fields #37706
Comments
`unsafe.Sizeof(hlc.Timestamp{})` was including XXX_sizecache, which was bloating the struct size even though it didn't have an effect on the encoded size of the timestamps, which we control in `encodeValue`. Even once we remove `XXX_sizecache` (cockroachdb#37706), it looks like `unsafe.Sizeof` will still include padding which we don't want to capture in the `encodedTsSize` constant, so this seems like the best approach. See https://play.golang.org/p/5swJSSbP6J4. Release note: None
38197: cli: warn the user if the time zone database is unavailable r=knz a=knz Fixes #23828. (The part in that issue about the database not being up to date cannot be fixed using the Go standard library - this does not give access to the search path and the version number. A comprehensive fix needs to wait for #36864.) Release note (cli change): CockroachDB will now print out an error message and an informative hint if the time zone database is unusable. 38214: storage/tscache: save 4 bytes per encoded tscache value r=ajwerner a=nvanbenschoten `unsafe.Sizeof(hlc.Timestamp{})` was including XXX_sizecache, which was bloating the struct size even though it didn't have an effect on the encoded size of the timestamps, which we control in `encodeValue`. Even once we remove `XXX_sizecache` (#37706), it looks like `unsafe.Sizeof` will still include padding which we don't want to capture in the `encodedTsSize` constant, so this seems like the best approach. See https://play.golang.org/p/5swJSSbP6J4. Release note: None Co-authored-by: Raphael 'kena' Poss <knz@cockroachlabs.com> Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
It looks like this is fixed by #37967. I'm surprised by this because I see this when compiling with Go 1.11.6 (before d0b7737). Still, the numbers don't lie:
I'm going to conclude that the regression is addressed and that the hypothesis in #37967 (review) was mostly accurate:
|
38404: proto: disable XXX_NoUnkeyedLiteral and XXX_sizecache fields r=nvanbenschoten a=nvanbenschoten Fixes #37706. The PR removes the `XXX_NoUnkeyedLiteral` and `XXX_sizecache` fields from generated protobufs. `XXX_NoUnkeyedLiteral` claims to come with a small perf win for proto marshaling, but it looks like it's only used with `proto.Marshal` and not with the `Marshal` method (which CRDB code and gRPC code always use). Meanwhile, it has two moderate disadvantages: 1. it adds 32 bits to every proto struct. This isn't a big deal in most cases, but in code that allocates large slices of little proto structs (like the `spanlatch.Manager`, which is what tipped me off to this new field), it has a non-negligible cost. 2. it makes value comparison between proto structs dangerously unreliable. We compare small protos by value all over the place (see `hlc.Timestamp`) and switching to an `Equals` method would come with a cost to code complexity and runtime performance. After removing `XXX_NoUnkeyedLiteral`, `XXX_sizecache` is now at the end of generated protos, it is now taking up space even though it is an empty struct: golang/go#9401. Since this is just a glorified lint which is already enforced by `go vet`'s “composites” check, it doesn't seem worth the cost. ### Benchmarks ``` name old reads/s new reads/s delta kv95/enc=false/nodes=3 35.5k ± 1% 35.8k ± 1% +0.86% (p=0.214 n=5+5) name old writes/s new writes/s delta kv95/enc=false/nodes=3 1.87k ± 2% 1.89k ± 2% +0.94% (p=0.214 n=5+5) ``` Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
For the reasons listed in the last two commits of the following branch, we would like to disable the autogenerated
XXX_NoUnkeyedLiteral
field and theXXX_sizecache
field in Go protobufs:https://github.com/nvanbenschoten/cockroach/commits/nvanbenschoten/sizeCache
However, this seems to cause a strange performance regression. To reproduce this, apply the following patch:
Build
cockroach
using./build/builder.sh mkrelease linux-gnu
. Finally, runroachtest run 'kv95/enc=false/nodes=3$'
. Without the patch, throughput should hover around 32k qps. With the patch, throughput drops to around 13k qps.The goal here is to figure out why. There must be an obvious explanation for this, but I haven't been able to find it. Debugging may require a combination of debugging the performance of running clusters and exploring micro-benchmarks.
The text was updated successfully, but these errors were encountered: