[caleballen]

Description

Use a pointer receiver for FileResolver. This was identified as a bug which led to reallocation and decrease in performance.

The speedup is for library users who call FileResolver more than once on the same file source: before this change, each call rebuilt the whole file index; now the index is built once and reused, so N calls cost the same as one (CLI scans call it once and are unchanged).

The benchmark calls FileResolver 1 or 5 times on a fresh fileSource per iteration, built from tar archives of 100, 1,000 and 10,000 files and from a single file; source setup is not timed (Apple M3 Pro, Go 1.27.3, -count 10, compared with benchstat).

Input	Calls	Time before	Time after	Δ time	Memory before	Memory after	Allocs before	Allocs after
tar, 100 files	1	6.35 ms	7.02 ms	~	1.01 MiB	1.01 MiB	6.8k	6.8k
tar, 100 files	5	32.3 ms	6.39 ms	−80%	5.05 MiB	1.01 MiB	34.1k	6.8k
tar, 1,000 files	1	46.0 ms	48.6 ms	~	8.10 MiB	8.10 MiB	47.0k	47.0k
tar, 1,000 files	5	238.7 ms	48.3 ms	−80%	40.5 MiB	8.10 MiB	234.9k	47.0k
tar, 10,000 files	1	498 ms	513 ms	~	76.3 MiB	76.3 MiB	444k	444k
tar, 10,000 files	5	2.46 s	499 ms	−80%	381.7 MiB	76.3 MiB	2.22M	444k
single file	1	100 µs	105 µs	~	35.7 KiB	35.7 KiB	352	352
single file	5	497 µs	105 µs	−79%	178.7 KiB	35.7 KiB	1,760	352

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Performance (make Syft run faster or use less memory, without changing visible behavior much)

Checklist

• I have added unit tests that cover changed behavior
• I have tested my code in common scenarios and confirmed there are no regressions
• I have added comments to my code, particularly in hard-to-understand sections

Issue references

[willmurphyscode]

Thanks @caleballen ! I looks like I have let the CI run expire, so I'll just close and open real quick to get a fresh run.

[willmurphyscode]

Thanks! Nice catch.