Explore ways of speeding up mass translated type reference resolution

[PathogenDavid]

https://github.com/InfectedLibraries/Biohazrd/issues/188 revealed some performance issues with our translated type reference resolution. We mostly rely on caching for it to perform well in most cases, but for transformations which rely on resolving every single type reference (like https://github.com/InfectedLibraries/Biohazrd/issues/188) the performance could definitely stand to be better on huge libraries like OpenCV.

Below are some ideas on how to fix this. Personally I'm inclined to think B or A are the ideal solution.

A) Implement transformation concurrency

https://github.com/InfectedLibraries/Biohazrd/issues/11

This should speed things up quite a bit on multi-core systems.

B) Implement a hint to pre-resolve everything and cache it

This would be a method on TranslatedLibrary to hint that we're about to resolve everything in the library. This would scan over the entire library and fill up the lookup caches. (This would avoid redundant scanning over the library for every translated type reference.)

C) Implement resolution lookup concurrency

Noting this since it's an idea that I had but I don't think it's the solution because:

A) https://github.com/InfectedLibraries/Biohazrd/issues/11 is would be a better form of concurrency. B) It would return unpredictable/erroneous results when a given Clang declaration or Biohazrd declaration ID resolve to the same translated declaration. (Right now in this situation it just returns the first result, which is predictable behavior.)

D) Implement smarter caching in the type references

The cache for individual translated type references is keyed on the library, but we could key it on a chain from the library to the resolved declaration. This would allow us to potentially re-use the cache if we find a matching parent in the chain, indicating that declaration subtree did not change.

I'm not extremely confident this would always fix our performance issues, and it'd be quite complicated to implement. I think it's likely it would be a performance win when A) lots of resolution is happening across the pipeline and B) most transformations only make small changes and C) the declaration tree isn't too deep. However if these are happening, I'd worry that the library isn't really complicated enough to justify needing this performance enhancement in the first place.

[PathogenDavid]

Marking this as very high since I don't think B will be all that hard to prototype and this performance issue is affecting InfectedOpenCV pretty heavily.