Improve linker performance by avoiding IndexOf

[Youssef1313]

Fixes #90717

@sbomer @vitek-karas These edits are done online as I currently don't have a local fork of runtime. In case this needed more changes or refactoring, would you be able to take it over?

[ghost]

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr, @marek-safar
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #90717

@sbomer @vitek-karas These edits are done online as I currently don't have a local fork of runtime. In case this needed more changes or refactoring, would you be able to take it over?

Author:	Youssef1313
Assignees:	-
Labels:	linkable-framework
Milestone:	-

[Youssef1313]

This loop will have maximum of three iterations. This is a lot better than IndexOf which will search through the whole instructions collection which can have thousands of elements.

[vitek-karas]

Should we even bother with the lookup then?
Can we measure this - if the lookup doesn't bring interesting perf wins I would vote for keeping it simple and just do the linear search over the known possible range (that should be really fast).

[Youssef1313]

@vitek-karas I'm not sure about the logic and wanted to avoid potentially changing the meaning of the code, e.g, I have no idea if the dictionary lookup could yield a different result than the loop. So, I wanted to make a change that is clear it doesn't change the code semantics, and at the same time is more performant.

Regarding measuring this, I currently don't have the dotnet/runtime cloned locally to try something (the changes in this PR are done through GitHub UI actually). But I think the performance trace is quite clear this lookup is problematic, and it also the change should hopefully be making sense as a performance improvement. Yet, I understand that measuring would still be a good idea to at least know how much improvement this is. But unfortunately, I'm not able to do it right now. If necessary, would someone from the team be able to do it?

[Youssef1313]

CI failure is looking unrelated to the change here:

    Wasi.Build.Tests.WasiTemplateTests.ConsoleBuildAndRunForDifferentOutputPaths(config: "Debug", appendRID: True, useArtifacts: False) [FAIL]
      Runtime pack path doesn't match.
      Expected: '/root/helix/work/workitem/e/dotnet-latest/packs/Microsoft.NETCore.App.Runtime.Mono.wasi-wasm/8.0.0-ci'
      Actual:   '/root/helix/work/workitem/e/dotnet-latest/packs/Microsoft.NETCore.App.Runtime.Mono.wasi-wasm/8.0.0-rc.1.23414.4'
      Stack Trace:
        /_/src/mono/wasi/Wasi.Build.Tests/BuildTestBase.cs(346,0): at Wasm.Build.Tests.BuildTestBase.AssertRuntimePackPath(String buildOutput, String targetFramework)
        /_/src/mono/wasi/Wasi.Build.Tests/BuildTestBase.cs(251,0): at Wasm.Build.Tests.BuildTestBase.BuildProject(BuildArgs buildArgs, String id, BuildProjectOptions options)
        /_/src/mono/wasi/Wasi.Build.Tests/WasiTemplateTests.cs(165,0): at Wasi.Build.Tests.WasiTemplateTests.ConsoleBuildAndRunForDifferentOutputPaths(String config, Boolean appendRID, Boolean useArtifacts)
           at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
           at System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(Object obj, Span`1 copyOfArgs, BindingFlags invokeAttr)

[sbomer]

Change LGTM, thanks!

[lewing]

failures are known (and resoved)