Good, I have no further comment for this update. Please go ahead.
I think there is a possible improvement by calling
Cipher.getInstance(algorithm) only one time for each transformation
algorithm. But may not worthy as the duplicated transformation
algorithm number is still small. I'm fine if you want to leave it as it is.
Thank you so much for your patient, especially for doing the benchmarking.
Thanks,
Xuelei
On 5/24/2019 1:53 PM, Martin Balao wrote:
Hi Xuelei,
On 5/24/19 5:17 PM, Xuelei Fan wrote:
If I understand correctly, you run the test with the patch of webrev01?
http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.01/
Yes, this is correct.
FIPS_without_8223482_webrev01.txt average: 358.42 ms
NON_FIPS_without_8223482_webrev01.txt average: 771.34 ms
If I understand correctly, you run the test with the pacth of webrev00?
http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/
No, this is not correct. "without_8223482" means no patch at all, just
the base line JDK (at revision fb0cfce19262, 2019-05-23).
In my opinion, it makes no sense to continue measuring Webrev.00 because
it has a considerable impact as shown by previous benchmarks.
From the above numbers, the FIPS_with_8223482_webrev01 is better than
FIPS_without_8223482_webrev01, but NON_FIPS_with_8223482_webrev01 is
worse than NON_FIPS_without_8223482_webrev01. It is a little bit
strange to me.
Yes, looks strange that FIPS with patch is better than without patch.
However, we need to consider that the difference is not a big one and
the margin of error we have. If you ask me, I'd say they are roughly the
same.
Did you have the numbers for the latest JDK build, without any patch?
As I said, "without" means the latest JDK without any patch.
Kind regards,
Martin.-
