Optimize UI updates of slicing panel

[FliegendeWurst]

Related Issue

This pull request resolves #3734.

Intended Change

• reduce UI update frequency of slicing panel to once every 500 ms
• reduce work done per rule application to the bare minimum

Alternative: add a listener that listens for macro finish and proof loaded events. Though I think we can afford updating the UI twice a second.

Type of pull request

• Bug fix (non-breaking change which fixes an issue)
• Refactoring (behaviour should not change or only minimally change)
• There are changes to the (Java) code

Ensuring quality

• I made sure that introduced/changed code is well documented (javadoc and inline comments).
• I have tested the feature as follows: UI still updates as expected
• I have checked that runtime performance has not deteriorated.

Additional information and contact(s)

The contributions within this pull request are licensed under GPLv2 (only) for inclusion in KeY.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.33%. Comparing base (e5853a5) to head (e41de91).
⚠️ Report is 80 commits behind head on main.

Files with missing lines	Patch %	Lines
...a/org/key_project/slicing/ui/SlicingLeftPanel.java	0.00%	10 Missing ⚠️
...java/org/key_project/slicing/SlicingExtension.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #3735      +/-   ##
============================================
+ Coverage     47.98%   50.33%   +2.34%     
+ Complexity    16045    15900     -145     
============================================
  Files          1683     1597      -86     
  Lines         96046    91015    -5031     
  Branches      15388    14548     -840     
============================================
- Hits          46091    45810     -281     
+ Misses        44683    39999    -4684     
+ Partials       5272     5206      -66     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[WolframPfeifer]

Thanks for the PR and fast response! However, in my opinion it would be better to have as little RuleAppListeners as possible, since that obviously is a per-rule overhead. Also, I think it would make sense to have MacroFinish and ProofLoaded events/listeners in any case.

[wadoon]

I thought the RuleAppListeners are disabled during the proof task. In general, we should rather put additional workload after the proof search.

In this case, the main workload is not to query the graph size of the slicing, rather to calculate the dependency at all.

[FliegendeWurst]

In the extension settings, there is an option "Always track dependencies". If it is not checked, the dependency graph will be created when needed later.