[WIP] Loading assembly references in parallel

[fadimounir]

While debugging multiple issues with crossgen2, i started noticing that the loading of references was slightly slow, especially that we reference *.dll from core_root and the test directory now.

On a cold run of crossgen2 to compile some random test and run it, it took 7292ms for just loading the references.

With the proposed changes, it takes only 900ms, so it's shaving off a good ~88% of the loading time on 8 cores. Multiply that by the number of P0/P1 tests, I believe this small win could be quite beneficial.

Thoughts?

@dotnet/crossgen-contrib

[trylek]

I'm somewhat worried that @MichalStrehovsky is probably the only person that can assess whether your proposed change is correct according to the CoreRT compiler design.

[fadimounir]

Unless i'm missing something, the work that seems to happen is metadata loading using the System.Reflection.MEtadata APIs. Places where we save what we loaded into a data structure have locks

[jkotas]

The CoreRT compiler design is loading all these lazily on demand. The only reason why we are doing this eager loading here is ProfileDataManager. Can we do this eager loading only when there are profile data for ProfileDataManager to use? Not doing the work would be superior to doing the work in parallel.

[fadimounir]

That's a good point, it does look like the eager loading is only tied to ProfileDataManager. I'll address that issue.

If we have profile data, is there a reason to not do this eager loading with parallelism?

[jkotas]

If we have profile data, is there a reason to not do this eager loading with parallelism?

That sounds fine.

[davidwrighton]

Also that ProfileDataManager is doing a lot of this loading in the assumption that it will be allowed to use the data. Mostly that isn't true, and we really should tweak what stuff is actually loaded.

[fadimounir]

cc @SrivastavaAnubhav if you'd like to pick that one up, since you were working on performance :)