[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: yafengio
Once this PR has been reviewed and has the lgtm label, please assign terrytangyuan for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	21e9283
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/68971e8c2397a40008aaa99d
😎 Deploy Preview	https://deploy-preview-1335--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Hi @yafengio. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Have we validated the concurrency limits here? In scale testing, simply creating a new rand object performed fine. I wasn't sure how the lock contention would perform in high concurrency situations

Have we validated the concurrency limits here? In scale testing, simply creating a new rand object performed fine. I wasn't sure how the lock contention would perform in high concurrency situations

Yes, I did a benchmark test. Compared with creating a new instance each time, the overhead of the lock is very small.

Hi @kfswain , optimized with sync.Pool to reduce lock overhead and added benchmark tests. Please review. Thx

hi @kfswain , do you have any other questions? If you think pr is unnecessary, I'll close it.

cc @nirrozenbaum @ahg-g

Benchmark_SafeRandShuffle/new_rand
Benchmark_SafeRandShuffle/new_rand-12         	   68043	     19829 ns/op	    5376 B/op	       1 allocs/op

Benchmark_SafeRandShuffle/safe_rand
Benchmark_SafeRandShuffle/safe_rand-12        	64563002	        16.04 ns/op	       0 B/op	       0 allocs/op

can you explain what are the numbers we see here? what is 68043 vs 64563002 for example?
if I got it right, the second column is nanosecond per Pick call, third column is bytes allocated per Pick call and fourth is allocation of new variable per call?

assuming that's the case - personally I would keep the simple version of creating a new variable which seems to be simplest and easiest to maintain. looking at the numbers, Pick with new rand generator creation takes less than 0.2 millisecond, while we're targeting to complete the whole scheduling in less than 10 ms.
it feels to me like a premature optimization.

Benchmark_SafeRandShuffle/new_rand
Benchmark_SafeRandShuffle/new_rand-12         	   68043	     19829 ns/op	    5376 B/op	       1 allocs/op

Benchmark_SafeRandShuffle/safe_rand
Benchmark_SafeRandShuffle/safe_rand-12        	64563002	        16.04 ns/op	       0 B/op	       0 allocs/op

can you explain what are the numbers we see here? what is 68043 vs 64563002 for example? if I got it right, the second column is nanosecond per Pick call, third column is bytes allocated per Pick call and fourth is allocation of new variable per call?

Yes, what you understand is correct.

assuming that's the case - personally I would keep the simple version of creating a new variable which seems to be simplest and easiest to maintain. looking at the numbers, Pick with new rand generator creation takes less than 0.2 millisecond, while we're targeting to complete the whole scheduling in less than 10 ms. it feels to me like a premature optimization.

OK. Thank you for your reply. I'll close this PR.