Investigate the resolver for potential performance gains

[volsa]

In one of our internal projects, plc check spends a good chunk of time in the resolver.
We should at least investigate if there are some potential performance gains.

(Note, this profile was done with --threads 1)

[riederm]

Not sure if we're hunting a ghost here...

to me it looks like that the long plateau does not reflect the time spent annotating, rather than the time spent waiting for a free thread from the threadpool to annotate (which happens in parallel to annotating). I suspect that what we see here is the behavior of the Par_Iter in rayon, when you only give it 1 thread.
I think we should at least see the TypeAnnotator::visit_unit(...) as well on this stack if it is really work spent in the annotation.

can we maybe have a call or something and look together - I sometimes find it hard to read flamegraphs correctly. maybe we can discuss it together.

[riederm]

do you still have the profiling file? the other thread would be more interesting

[volsa]

Sadly no but it should be reproducible, might do that tomorrow. I did some further quick (time-based) profiling and got the following results (again with --threads=1). Does this mean the assumption with rayon is incorrect? Do we need to look into visit_statement_control? Anyways, I'll take a closer look at this tomorrow and perhaps ping you if you have time.

[volsa]

Closing this in favor of #1189