Modernize and minor performance improvements

[costela]

About the changes

This PR does a couple of smaller things:

• first we make the benchmarks a bit more realistic by actually adding features (makes IsEnabled less of a noop)
• drop usage of reflect by making every generic
• initialize allConstraints to its proper size to avoid multiple slice resizings

The changes above bring a measurable performance improvement:

goos: linux
goarch: amd64
pkg: github.com/Unleash/unleash-go-sdk/v5
cpu: 12th Gen Intel(R) Core(TM) i7-1250U
                           │  0-old.out  │          3-makeslice.out           │
                           │   sec/op    │   sec/op     vs base               │
FeatureToggleEvaluation-12   1.546µ ± 4%   1.455µ ± 4%  -5.86% (p=0.002 n=10)

                           │  0-old.out   │           3-makeslice.out           │
                           │     B/op     │     B/op      vs base               │
FeatureToggleEvaluation-12   1.383Ki ± 0%   1.328Ki ± 0%  -3.95% (p=0.000 n=10)

                           │ 0-old.out  │          3-makeslice.out           │
                           │ allocs/op  │ allocs/op   vs base                │
FeatureToggleEvaluation-12   13.00 ± 0%   11.00 ± 0%  -15.38% (p=0.000 n=10)

Additionally, we also do a couple of minor internal cleanups:

• switch to math/rand/v2
• modernize with golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize
• move more code to using stdlib
• do not ignore errors in storage.Reset

Important files

The biggest impact is caused by the change in utils.go, in the every function.
Followed by the slice initialization in client.go.

In general, since the PR has multiple parts, it may be easier to check each commit individually.

Discussion points

Since there's a lot going on in the PR, one could argue for splitting it into smaller ones.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[costela]

This is not stale 🙄

[FredrikOseberg]

@costela Sorry for the delay, but we have had a lot going on as well as going on a company offsite last week that we do once a year. I haven't had time to sit down and contemplate the changes here in detail. My main concern is whether or not we need to do a major release with the interface changes.

I hope I can take a better look at this next week.

[FredrikOseberg]

@costela

Could you lessen my workload a bit by highlighting the key implications of these changes?

[costela]

@FredrikOseberg Sure!

• The first commit (26727f4) just gives us a more realistic baseline for benchmarking, using more of the IsEnabled code paths. No user-facing implications. ✔️
• The second (8d83f29) is just the result of calling modernize, so it should have no implications ✔️
• The third (aa9397d) just removes dead code and replaces custom rounding in tests with math.Round. So hopefully no implications either ✔️
• The fourth (91a442f) is a bit more interesting: it switches to defer for some unlocking since it has been pretty on-par performance-wise for a long time, and is marginally safer. It also replaces math/rand with math/rand/v2, just out of force of habit 🙈 It should have no sensible implications for consumers, but may require a bit more scrutiny. 🕵️
• The fifth (9f05cd0) drops reflect usage in the internal every function. It causes a measurable performance improvement (see benchmarks in OP) and should have no side-effects, since it implements basically the same checks as before, just on compile time.
• The sixth (9becd32) could also use some scrutiny: we now bubble any errors during storage reset. I believe this is safer than ignoring the error, but I may be overlooking some side-effects. 🕵️
• And lastly the seventh (4912388) is a pretty straightforward micro-optimization and just pre-allocates the allConstraints slice to the worst-case larges capacity. Seems pretty safe? ✔️

[costela]

@FredrikOseberg just a friendly ping, to avoid this getting forgotten 😇

I totally get it if there's no time or mental capacity available for such a "bag of stuff" PR
🙈

I'm just looking forward to the performance gains, since we use unleash in some hot-path contexts.

[FredrikOseberg]

@FredrikOseberg just a friendly ping, to avoid this getting forgotten 😇

I totally get it if there's no time or mental capacity available for such a "bag of stuff" PR 🙈

I'm just looking forward to the performance gains, since we use unleash in some hot-path contexts.

@costela I haven't forgotten about this, but I have some deadlines on other feature enhancements in Unleash that have taken up most of my capacity for the past weeks. I will pick this up as soon as I can.

[sighphyre]

This looks great, thanks so much for doing this!