-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[QD-7638] Support multiple (& possibly different) fingerprint versions #13
Conversation
Qodana for JVMIt seems all right 👌 No new problems were found according to the checks applied ☁️ View the detailed Qodana report Dependencies licensesThird-party software listThis page lists the third-party software dependencies used in qodana-sarif
Contact Qodana teamContact us at [email protected]
|
@avafanasiev / @hybloid PTAL. This also passes with all test-data in IJ |
Qodana for JVMIt seems all right 👌 No new problems were found according to the checks applied View the detailed Qodana reportTo be able to view the detailed Qodana report, you can either:
To get - name: 'Qodana Scan'
uses: JetBrains/[email protected]
with:
upload-result: true Dependencies licensesThird-party software listThis page lists the third-party software dependencies used in qodana-sarif
Contact Qodana teamContact us at [email protected]
|
sarif/src/main/java/com/jetbrains/qodana/sarif/baseline/Baseline.kt
Outdated
Show resolved
Hide resolved
undecidedFromBaseline.each { result -> | ||
val foundInReport = result.equalIndicators | ||
.flatMap(reportIndex::getOrEmpty) | ||
.filter(undecidedFromReport::remove) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very ineffective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is, but it still outperforms a Set
based calculation because of the heavy hashCode
, at least for the reports I checked (100/1000/10_000 results). The new algorithm also outperforms the old implementation on these.
Do you have a suggestion to improve here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So running through ArrayList with equals and then removing element from the middle of it is ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100k is also quite possible.
val undecidedFromBaseline = baseline.results.noNulls() | ||
.filterNot { it.baselineState == BaselineState.ABSENT } | ||
.onEach { result -> baselineIndex.add(ResultKey(result), result) } | ||
.toMutableSet() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, now you have 4 different hashes? Result has very heavy hashcode and equals calculation.
|
||
private typealias Fingerprint = String | ||
private typealias StrictIndex = MultiMap<Fingerprint, Result> | ||
private typealias LaxIndex = MultiMap<ResultKey, Result> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably dont need here result, counter would be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice, just found that when using a counter I can drop the Set
conversion from undecidedFromBaseline
undecidedFromBaseline.each { result -> | ||
val foundInReport = result.equalIndicators | ||
.flatMap(reportIndex::getOrEmpty) | ||
.filter(undecidedFromReport::remove) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So running through ArrayList with equals and then removing element from the middle of it is ok?
undecidedFromBaseline.each { result -> | ||
val foundInReport = result.equalIndicators | ||
.flatMap(reportIndex::getOrEmpty) | ||
.filter(undecidedFromReport::remove) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100k is also quite possible.
c8f3493
to
7afc841
Compare
sarif/src/main/java/com/jetbrains/qodana/sarif/baseline/Baseline.kt
Outdated
Show resolved
Hide resolved
foundInReport -> remove() | ||
!options.wasChecked.apply(result) -> { | ||
remove() | ||
.filter { result -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i didn't like the style than filter lambda produces side effects, it's quite counterintuitive and leads to poor code readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree in principal, but I think it's also common that filter()
calls do things like set.add
or counter checks.
Anyway, refactored out all but two very simple side-effects, where refactoring would make it less clear imho
!options.wasChecked.apply(result) -> { | ||
remove() | ||
.filter { result -> | ||
val foundInReport = result.equalIndicators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it means we are comparing hashes v1 against v2. It shouldnt be really bad for performance. But it could be important for correctness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed that. For now it doesn't affect correctness, because the hash algorithms are not compatible with each other. An alternative approach could also be to first determine which version of fingerprint to use, but I don't think it's necessary atm.
The RunResultGroup class has been simplified, reducing the complexity of baseline calculation. The changes include renaming FingerprintIndex and KeyIndex to StrictIndex and LaxIndex, respectively, and streamlining processes to efficiently manage report results with state. Several baseline calculation steps have been modified, enhancing the diff creation process and making the code more concise. In addition, a test has been temporarily disabled due to outdated test data.
- Keep only single result set - Reduce number of iterations
Also convert most `Set` to list, as hashCode comparison turned out to be useless.
7afc841
to
f15c836
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Completely rewrote the algorithm for baseline calculation, as it had two major problems when dealing with fingerprints:
v1
prints, and now a new report which containsv1
andv2
prints, issues would no longer be compared correctly. This means, introducing av2
would break all existing baselines immediately. (The opposite is also true: a baseline generated withv1
andv2
could not be successfully compared to a report containing onlyv1
)The commit chain reflects the path I took and can be reviewed individually. But I will squash the the PR in the end.