Bug #20998
Updated by Nicolas CHARLES about 2 years ago
Compliance percentage computation in ComplianceLevel is not correct, which causes several surprising results in the Rules or API results A rule with 200 compliant, 199 repaired, 1 error, 1 non compliant, and 1 missing will result in 47% success, 50% repaired, and 1% for each (with a precision of 0 digits after the comma) As we can see here ( https://stackoverflow.com/questions/13483430/how-to-make-rounded-percentages-add-up-to-100 ) it is a complex topic h2. Our constraints We must not remove small values (one error in 10000 should show up). So we need a minimal value based on precision We want to keep the order in the compliance: showing that we have more repaired than success when it's the opposite is really surprising The result must sum to 100 It seems there are no best solutions for that; maybe a variant on https://stackoverflow.com/questions/13483430/how-to-make-rounded-percentages-add-up-to-100#34959983 would do the trick h3. Side note on performance Current implementation makes making many small objects there Most of the time, in API request (so for the UI as well), we do withoutPending.computePercent().compliance withoutPending copy the object computePercent creates lists, a CompliancePercent and finally compliance gets only success+repaired+notApplicable+compliant+auditNotApplicable we could skip the middle men and do the computation directly on the percents, with 0ing the pending, and not creating the percents, but percents Totally removing the computation there, for everything in no answer, make the end it doesn't makes it much faster API respond in 2s rather than 4.5s Indeed, computing compliance Impact for 6500 real compliance level takes a whooping 149ms, cutting the middle men removes nearly nothing. Tuning a bit around the BigDecimal (having a default of precision 2 that we don't recomputes) saves nearly 30% So in the end, it's really the BigDecimal that is expensive ought to be much better