System.Reflection.Metadata: Avoid allocations in custom attribute parser

[MichalStrehovsky]

The custom attribute parser allocates an ImmutableArray for FixedArguments and NamedArguments.

We should explore options to parse these lazily and avoid the array allocation.

[joshfree]

@tmat

[karelz]

Next step: We need real scenario demonstrating the perf issue, so that we can measure the improvement and if it is worth the effort.
Steps afterword: Design API.

Note: Roslyn scenario probably doesn't care says @tmat.

[MichalStrehovsky]

We need real scenario demonstrating the perf issue

This is about API consistency. The rest of the APIs in S.R.Metadata tries hard to avoid allocations (which is why we chose to use it in the CoreRT compiler) and this one doesn't even try.

If it's not fixed, we might end up just not using S.R.Metadata's parser in CoreRT and roll our own. It's not rocket science and other people can do it too. It's a question of whether S.R.Metadata wants to be a one stop solution for people who want to read metadata without allocations or not.

[joelverhagen]

Next step: We need real scenario demonstrating the perf issue, so that we can measure the improvement and if it is worth the effort.
Steps afterword: Design API.

Regarding this comment, I think an additional factor is not just performance but also edge case handling. There exists badly formatting DLLs (I have found several on NuGet.org) that have corrupted array length attributes causing one of these allocations to exceed many GBs of memory, per #57531.

I have been using System.Reflection.Metadata as a high performance DLL analysis tool and in nearly all places it processes DLLs with very low memory consumption. This problem appears to be an outlier from an API consistency standpoint.