⚡ Optimize parseChecksum to reduce allocations

[giankpetrov]

💡 What: Optimized the parseChecksum function in updater/updater.go by replacing strings.Split and strings.Fields with manual string manipulation.

🎯 Why: strings.Split allocates a new slice containing all lines, which is unnecessary memory overhead for potentially large checksum files. strings.Fields also creates a slice and multiple strings for each line.

📊 Measured Improvement:

Execution Time: ~6.8x faster (from 154,019 ns/op to 22,540 ns/op for 1000 lines).
Allocations: Reduced from 1,002 allocs/op (48,416 B/op) to 0 allocs/op (0 B/op).
Robustness: Now correctly handles filenames with spaces, which was a limitation of the previous strings.Fields implementation.

[github-actions]

Warning

This branch is 11 commit(s) behind main and will need to be updated before it can be applied cleanly.

Please sync your fork and rebase before continuing:

# If you have upstream configured
git fetch upstream
git rebase upstream/main
git push origin perf-optimize-parse-checksum-17229353039594671266 --force-with-lease

# Or if your fork's main is already synced via GitHub UI
git fetch origin main
git rebase origin/main
git push origin perf-optimize-parse-checksum-17229353039594671266 --force-with-lease

See CONTRIBUTING.md for the full guide.

[AgusRdz]

Thanks @giankpetrov! Really clean optimization — replacing strings.Split/strings.Fields with direct strings.IndexByte slicing is exactly the right call for a hot path like checksum parsing. Zero allocations, 6.8x faster, and the bonus fix for filenames with spaces is a nice touch. Appreciate the benchmark too, makes the improvement easy to verify. 🚀