On 11/11/2022 14:39, Rémy Maucherat wrote:
On Fri, Nov 11, 2022 at 3:24 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
FYI: the performance check TestMessageBytes.testConversionPerformance()
seems to fail sometimes for various Linux variants and JVM versions. It
fails in 13 out of 116 combinations of Linux distro, JVM version and
provider and connector.
When failing, it complains, that the non-optimised version is faster,
then the optimised one. The speed difference is between one and 24 percent.
The system on which the tests run is CPU limited. Most failures seem to
happen with JDK 17, but that could be just because during those runs
might have been most concurrent things happening on the underlying
virtualization host.
Maybe one could move the testConversionPerformance test into a separate
class handled by the existing test.excludePerformance?
I never had the test fail, but looking at the output of the test it's
quite close.
1313899820 1102482207
1049725589 991728960
849182074 917795195
So the first two iterations would fail, but the test passes because
the final one is slightly faster. The comment says it should be 3x to
4x faster, it's not happening anymore. It simply means the char to
bytes of the JVM got better in newer versions.
I see similar results.
For Java 11 I see almost an order of magnitude improvement with the
optimised version. For Java 17 the optimised version has a marginal
benefit. It is close enough that the test coudlk fail over a large
number of runs.
To some extent, the test has done its job. It has told us when we can
remove the optimisation - once the minimum version is Java 17.
What if we adjusted the test so it din't run on Java 17 and later and we
comment the optimisation (and the test) to remind us to remove it once
Java 17 is the minimum version?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
