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 https://github.com/kubernetes/kubernetes/issues/53327
We recently started seeing a 50% decrease in scheduling throughput (for e.g in kubemark-500 scale job) and turns out https://github.com/kubernetes/kubernetes/pull/53135 introduced it.
The reason is [this call](2caae38d32/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
f1d9962fec