Severe performance degradation when enabling resource tracking #5988
Description
What happened?
While developing #5940, I made use of the (at that time optional) resource tracking to determine whether a resource originated from a specific generator.
Relevant change:
https://github.com/kubernetes-sigs/kustomize/pull/5940/files#diff-0a2a043ac09e972046124503e8c93e4e7141cfc13deff446afb1aa3e328ee8c5L130-L134
After this code was merged, @ephesused reported a significant performance regression. I confirmed this and traced it back to the resource tracking logic, which was now always enabled.
In #5971, I introduced a partial revert: using an internal annotation as a workaround to identify the resource origin, rather than relying solely on resource tracking.
What did you expect to happen?
- Resource tracking should not introduce a 20× performance slowdown.
- The workaround (using an annotation to track internal state) should eventually be removed. Instead, resource tracking should be improved so it can be used internally without negatively affecting performance.
I also believe the output YAML is not the right place to store internal configuration metadata, so any long-term fix should avoid relying on annotations for internal tracking.
How can we reproduce it (as minimally and precisely as possible)?
Performance test script can be found here: #2869
Expected output
No response
Actual output
No response
Kustomize version
kustomize/v5.7.1
Operating system
Linux