feat: reduce memory allocs to optimize performance

[pboyd04]

Benchstat comparison of before and after. The only things showing + are down in the nanosecond range and well within the noise ratio. This basically does what it can to get rid of as many allocs as possible which helps to increase the speed.
goos: linux
goarch: amd64
pkg: github.com/casbin/govaluate
cpu: 13th Gen Intel(R) Core(TM) i7-13700H
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
SingleParse-20 626.5n ± 4% 601.0n ± 3% -4.08% (p=0.035 n=10)
SimpleParse-20 4.110µ ± 3% 3.414µ ± 5% -16.95% (p=0.000 n=10)
FullParse-20 19.64µ ± 4% 12.91µ ± 10% -34.30% (p=0.000 n=10)
EvaluationSingle-20 13.31n ± 5% 13.86n ± 12% +4.09% (p=0.043 n=10)
EvaluationNumericLiteral-20 49.12n ± 2% 51.68n ± 3% +5.19% (p=0.000 n=10)
EvaluationLiteralModifiers-20 116.8n ± 2% 130.4n ± 15% +11.69% (p=0.000 n=10)
EvaluationParameter-20 45.04n ± 3% 37.70n ± 10% -16.30% (p=0.000 n=10)
EvaluationParameters-20 78.52n ± 1% 69.56n ± 14% -11.42% (p=0.030 n=10)
EvaluationParametersModifiers-20 167.3n ± 2% 161.1n ± 2% -3.74% (p=0.000 n=10)
ComplexExpression-20 42.28n ± 3% 33.97n ± 1% -19.65% (p=0.000 n=10)
RegexExpression-20 1.320µ ± 1% 1.252µ ± 3% -5.15% (p=0.000 n=10)
ConstantRegexExpression-20 384.4n ± 3% 310.2n ± 8% -19.29% (p=0.000 n=10)
Accessors-20 142.2n ± 3% 127.7n ± 4% -10.23% (p=0.015 n=10)
AccessorMethod-20 788.7n ± 2% 800.6n ± 2% +1.51% (p=0.041 n=10)
AccessorMethodParams-20 906.3n ± 2% 911.8n ± 2% ~ (p=0.353 n=10)
NestedAccessors-20 199.4n ± 2% 194.1n ± 3% -2.68% (p=0.009 n=10)
geomean 273.7n 251.1n -8.28%

[CLAassistant]

All committers have signed the CLA.

[github-actions]

🎉 This PR is included in version 1.4.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[hsluoyz]

@pboyd04 you can create PR in Casbin repo

[see-sharp-dev]

@hsluoyz @pboyd04 this change started to break our tests (that run in parallel with t.Parallel()) because of the detected data races.

WARNING: DATA RACE
Read at 0x00c00003c170 by goroutine 28:
  github.com/casbin/govaluate.parseTokens()
      /xxx/vendor/github.com/casbin/govaluate/parsing.go:60 +0x548
  github.com/casbin/govaluate.NewEvaluableExpressionWithFunctions()
      /xxx/vendor/github.com/casbin/govaluate/EvaluableExpression.go:100 +0xb4
  github.com/casbin/casbin/v2.(*Enforcer).getAndStoreMatcherExpression()
      /xxx/vendor/github.com/casbin/casbin/v2/enforcer.go:838 +0x90
  github.com/casbin/casbin/v2.(*Enforcer).enforce()
      /xxx/vendor/github.com/casbin/casbin/v2/enforcer.go:696 +0xd10
  github.com/casbin/casbin/v2.(*Enforcer).Enforce()
      /xxx/vendor/github.com/casbin/casbin/v2/enforcer.go:849 +0x230

[hsluoyz]

@see-sharp-dev can you contribute your tests to this public repo to help resolve the regression this time and in future?

[see-sharp-dev]

@hsluoyz I'm not really familiar with the repo and code. we use casbin and after updating indirect modules our casbin tests started to fail.

an example of what I meant is here

[pboyd04]

I can add some locking to prevent the "race". it shouldn't be a real problem since all that should be able to happen here is that one of the parallel govalute parses overwrites the sample size from another. This shouldn't have any impacts outside the library. But yeah I can make it cleaner.

[see-sharp-dev]

This shouldn't have any impacts outside the library

actually it does, because we use casbin enforcer which under the hood uses this library here. and after bumping indirect packages this issue appeared.

[pboyd04]

It's trivial to fix. All you need is a mutex around the samples array. I'll do it when I get some time. Should be this evening or next.

[pboyd04]

Fixed in #15