Open github-actions[bot] opened 1 month ago
re: #5981 -- that may address the memory measure, which is so often noise. But it won't explain the time discrepancy of " 1.48 | load.ugrid.DataRealisation.time_realise_data(200000)" On the other hand, the step from workflows 2024.08.0 to 2024.08.1 only changes the pre-commit config, so I guess the time discrepancy must probably be spurious. Worth checking, though ?
@pp-mo what this perhaps DOES show is that time_realise_data
is too vulnerable to noise?
@pp-mo what this perhaps DOES show is that
time_realise_data
is too vulnerable to noise?
Well that seems reasonable in a way.
But we have lived with it up to now, and if there is severe variability expected in these tests, I don't recall having seen a lot of it before. So perhaps it is a recent phenomenon ?
So perhaps it is a recent phenomenon ?
Agreed, but I don't know why. Dask is changing all the time. Difficult to know what to do - milliseconds would normally be long enough to dial out noise.
I was a bit trigger happy linking this one, re-opening
Benchmark comparison has identified performance shifts at:
Please review the report below and take corrective/congratulatory action as appropriate :slightly_smiling_face:
:stopwatch: Performance Benchmark Report: b8f554f7
Performance shifts
``` | Change | Before [c88b4076]Full benchmark results
``` Benchmarks that have stayed the same: | Change | Before [c88b4076]Generated by GHA run
10396204733