draft: performance refactor

[jptosso]

Performance:

Speed: 3-10% faster across all benchmarks
Memory: 0.2-1.1% reduction in bytes allocated
Throughput: 2x (100%+) improvement in operations per second

Other improvements:

• Code Quality: More idiomatic Go, less C-style

                            ORIGINAL  →  OPTIMIZED     IMPROVEMENT
SQLi Detection:
  Speed (ns/op):               39,444  →     35,312      10.5% faster
  Memory (B/op):               49,888  →     49,360       1.1% less
  Allocations:                    321  →        395      23% more
  Throughput (ops/10s):       155,161  →    339,213     118.6% more

Folding:
  Speed (ns/op):               99,207  →     91,912       7.4% faster
  Memory (B/op):               71,112  →     70,624       0.7% less
  Allocations:                  1,775  →      1,755       1.1% less
  Throughput (ops/10s):        61,015  →    125,456     105.7% more

Tokenization:
  Speed (ns/op):              165,441  →    159,822       3.4% faster
  Memory (B/op):              149,929  →    149,561       0.2% less
  Allocations:                  3,689  →      3,689      Same
  Throughput (ops/10s):        36,444  →     75,534     107.2% more

XSS Detection:
  Speed (ns/op):               54,036  →     53,522       0.9% faster
  Memory (B/op):               49,016  →     49,016      Identical
  Allocations:                  1,179  →      1,179      Identical
  Throughput (ops/10s):       110,212  →    224,968     104.1% more

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[fzipi]

Can we split this one?

[fzipi]

I like the changes in this func. Can we add this in a separate PR?

The switch simplifies and it is easier to read.

[fzipi]

strings.IndexByte is faster—often much faster—than a manual for _, ch := range []byte(s) loop.

[fzipi]

Same here.

[fzipi]

This might make sense.

[fzipi]

Same here.