On Wed, 17 Jul 2024 15:35:26 GMT, Fernando Guallini <fguall...@openjdk.org> wrote:
>> The manual test Cipher/DES/PerformanceTest.java fails with >> ArithmeticException due to potential division by zero. The issue arises when >> calculating the elapsed time using end - start, which could result in zero >> milliseconds if start and end are identical due to the high speed of >> execution. This leads to a division error in the following code snippet: >> >> >> start = System.currentTimeMillis(); >> end = System.currentTimeMillis(); >> int speed = (int)((data.length * count)/(end - start)); >> >> This issue is easily reproducible on platforms where >> System.currentTimeMillis() has low granularity, such as many versions of >> Windows, end and start can be equal when obtaining >> System.currentTimeMillis() if the test runs very quickly. >> >> The fix is to use System.nanoTime() instead, which is designed to measure >> elapsed time with very high precision. This value is then converted to >> microseconds so the tests can properly calculate the throughput (bytes >> processed per microsecond) for the report. Example output: >> >> >> Algorithm DataSize Rounds Bytes/microsec >> DES/ECB/NoPadding 1024 100 66 >> DES/ECB/NoPadding 1024 1000 50 >> DES/ECB/NoPadding 8192 100 70 >> DES/ECB/NoPadding 8192 1000 70 >> Average: 64 > > Fernando Guallini has updated the pull request incrementally with one > additional commit since the last revision: > > byter per microsec LGTM. Have you run test with iterations to ensure stability. This will be a tier1 test so intermittent failures are not acceptable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20135#issuecomment-2238072971
