Severe performance degradation when enabling resource tracking

[Skaronator]

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?

1. Resource tracking should not introduce a 20× performance slowdown.
2. 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

[koba1t]

/triage accepted

[koba1t]

/cc @koba1t

[aryasoni98]

I came across this issue and would love to contribute could you please assign it to me?

[koba1t]

We welcome your contribution!

/assign aryasoni98

[aryasoni98]

/assign