Add an API for releasing cached DIEs to improve iteration performance

[grahamroff-dev]

Add CompileUnit.clear_DIE_cache() and an optional release_dies argument to DWARFInfo.iter_CUs(). This allows consumers iterating over each compile unit to release the DIE graph after processing it, significantly reducing peak memory usage. In a test parsing a 30MB elf file this reduces the maximum RAM usage from 1.8 GB to about 190 MB, with a resulting non-trivial boost in performance.

Preserve the existing caching behavior by default and add tests for explicit release, automatic release, and reparsing after release.

Relates (as an alternate solution) to #626

[eliben]

@sevaa wdyt about this alternative?

@grahamroff-dev the new method seems OK to me, but I'm less sure about modifying iter_CUs. Theoretically callers can do the same themselves, if they need to? (this would require invoking a "private" method, but maybe we can expose that -- or people can just reach to it since the use case is niche)

[sevaa]

I am not a fan of building up the cache then discarding it, rather than not building in the first place.

The proposed change to iter_CUs() alleviates only one particular OOM pathway - firehose parsing through a lot of CUs, each reasonably sized. OOM on overlarge CUs won't be affected.

The forced "clear the cache" method might be useful, we should keep it - for those consumers who won't mind managing the cache manually to avoid those OOMs.

[grahamroff-dev]

Disabling the cache completely seems more intrusive, and is targeting (I think) an even narrower use-case - processing a single very large CU where limiting memory completely trumps performance. The per-CU DIE cache provides a good performance boost while processing that CU:

• Reference resolution reuses commonly referenced DIEs, especially types.
• Child/parent traversal relies on cached parent and terminator relationships.
• Repeated lookups return the same DIE object.
• Without caching, operations such as repeated get_parent() can become very expensive.

but it provides little benefit after moving to another CU unless the caller revisits that CU or follows a cross-CU reference. So the cache cleaning between CUs works a good memory optimization without affecting iteration performance.

I can remove the change to the iter_CUs(), the caller can just directly call clear_DIE_cache() after processing each CU. Is that the preferred direction?

[eliben]

I can remove the change to the iter_CUs(), the caller can just directly call clear_DIE_cache() after processing each CU. Is that the preferred direction?

Yes, this would be preferable

[grahamroff-dev]

Done, PR updated to just add the new cache clearing API.

[eliben]

This PR now LGTM.

Will merge in the next few days unless @sevaa has objections

[sevaa]

No objections.