perf: improve job selection performance in case of potential ambiguity that is resolved by comprehensive ruleorder statements.

[johanneskoester]

QC

• The PR contains a test case for the changes or the changes are already covered by an existing test case.
• The documentation (docs/) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behavior or functionalities of Snakemake).

[johanneskoester]

@dkuzminov you probably want to have a look at this?

[github-actions]

Please format your code with black: black snakemake tests/*.py.

[dkuzminov]

Overall this improvement is incorrect. Assume there is a job primary that dominates all other jobs. Next, imagine that this rule is disregarded later because of missing input. We would get an incorrect is_strictly_ordered value because we know nothing about the ordering of the rest of the jobs. We would select the first producer (other than primary) even if it is ambiguous.

[dkuzminov]

This is not correct, as the first element shall be compared to the rest of the elements:

is_strictly_ordered = all(primary_job > job for job in jobs[1:])

[johanneskoester]

good catch!

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[johanneskoester]

Overall this improvement is incorrect. Assume there is a job primary that dominates all other jobs. Next, imagine that this rule is disregarded later because of missing input. We would get an incorrect is_strictly_ordered value because we know nothing about the ordering of the rest of the jobs. We would select the first producer (other than primary) even if it is ambiguous.

Right, I missed that case indeed. I have worked a bit on it. Still not 100% validated in my mind, but I think this is more correct (although it is 10pm here now, so I might miss something again ;-)).

[johanneskoester]

I think it is fine.