You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Optimize random string generator to avoid multiple locks & use bit-masking
Ref kubernetes#53327
We recently started seeing a 50% decrease in scheduling throughput (for e.g in kubemark-500 scale job) and turns out kubernetes#53135 introduced it.
The reason is [this call](https://github.com/jsafrane/kubernetes/blob/2caae38d323720a96be34606589f41488ba82b87/plugin/pkg/scheduler/algorithm/predicates/predicates.go#L272) to create a random 32-length string.
From the code of the `rand` utility (which is being heavily used throughout the system for randomizing object names), I noticed following performance issues:
- to create an n-length string, we are making n calls to `rand.Intn()` each of which does a lock+unlock operation on the RNG.. while just 1 lock+unlock operation is enough for all
- we're choosing one character (from an alphabet of 27 chars) per each random integer.. while we can select 10 characters using a single int63 (by masking and bit-shifting) as 1 character uses just 5 bits of randomness
- the character set is defined as a global slice (mutable), so the compiler needs to fetch length of the slice on each invocation to `len()` (we're making n of those).. while we can just use a const string (immutable) which will make len directly available as a cached constant (yes, go does it!)
This PR is making the above fixes. I'll try to add some benchmarking to measure the difference (as @wojtek-t suggested).
/cc @kubernetes/sig-scalability-misc @kubernetes/sig-scheduling-bugs @kubernetes/sig-api-machinery-misc @wojtek-t@smarterclayton
0 commit comments