In bringing back Clayton's PR piece-by-piece this was almost as easy to
implement as his version, and is much more like what I think we should be
doing.
Specifically, any time which defines a .DeepCopy() method will have that method
called preferentially. Otherwise we generate our own functions for
deep-copying. This affected exactly one type - resource.Quantity. In applying
this heuristic, several places in the generated code were simplified.
To achieve this I had to convert types.Type.Methods from a slice to a map,
which seems correct anyway (to do by-name lookups).
His PR cam during the middle of this development cycle, and it was easier to
burn it down and recreate it than try to patch it into an existing series and
re-test every assumption. This behavior will be re-introduced in subsequent
commits.
Automatic merge from submit-queue
Resource quantity must support leading and trailing whitespace in JSON for back-compat
For backwards compatibility reasons, we must continue to support leading or trailing whitespace on Quantity values when deserialized from JSON. We must also support numbers serialized into yaml (`cpu: 1`) and JSON (`"cpu": 1`)
Fixes#26898
Instead of saving bytes, save a string, which makes String() faster
and does not unduly penalize marshal. During parse, save the string
if it is in canonical form.
Provides fast transformations of int64 scaled values with overflow to
inf.Dec as needed. Attempts to reduce allocations and expensive
operations in the critical path.
Alters the public signature of Quantity to encourage more efficient use
Treat `nil` Amount as 0 in `resource.Quantity.Add` and
`resource.Quantity.Sub`. Also, allow adding/subtracting resources with
different Formats (since Format has no effect on the underlying value).
The original scale function takes around 800ns/op with more
than 10 allocations. It significantly slow down scheduler
and other components that heavily relys on resource pkg.
For more information see #18126.
This pull request tries to optimize scale function. It takes
two approach:
1. when the value is small, only use normal math ops.
2. when the value is large, use math.Big with buffer pool.
The final result is:
BenchmarkScaledValueSmall-4 20000000 66.9 ns/op 0 B/op 0 allocs/op
BenchmarkScaledValueLarge-4 2000000 711 ns/op 48 B/op 1 allocs/op
I also run the scheduler benchmark again. It doubles the throughput of
scheduler for 1000 nodes case.
make etcd registry pass test
fix kubelet config for quantity
fix openstack for quantity
fix controller for quantity
fix last tests for quantity
wire into binaries
fix controller manager
fix build for 32 bit systems
