search

PLC-lang / rusty

Structured Text Parser and LLVM Frontend
GNU Lesser General Public License v3.0
181 stars 47 forks source link

Investigate the resolver for potential performance gains #1185

Closed volsa closed 1 month ago

volsa commented 1 month ago

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.

Screenshot 2024-03-28 at 12 30 29

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

riederm commented 1 month ago

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 commented 1 month ago

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

volsa commented 1 month ago

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.

Screenshot 2024-04-02 at 17 40 53
volsa commented 1 month ago

Closing this in favor of https://github.com/PLC-lang/rusty/issues/1189