Possible unnecessary image builds in JFR perf test

[roberttoyonaga]

Do we need to rebuild the JFR perf test app for each test configuration? Currently each app is being built twice (resulting in 4 native builds each time jfrPerfTestRun is called.) This results in a total of 8 image builds for all the JFR perf tests.

Both test endpoints are included in each JFR app so there's no need to rebuild based on the endpoint we are hitting in the hyperfoil benchmark. I think the tree could look like this instead:

This should almost cut the test time in half because the build is probably the lengthiest part. What do you think? If you agree we can reduce the number of builds, I'm happy to submit a follow up PR.

[jerboaa]

@Karm PTAL.

[Karm]

Thx @roberttoyonaga Lemme take a look. Given the way Mandrel is installed, I rarely run local & container at the same time, so it entirely escaped me that when you do it's rebuilt again.

[Karm]

@roberttoyonaga I can see the app being built twice for the same set of flags too:

$ grep -e "Command.* package " ./testsuite/target/archived-logs/org.graalvm.tests.integration.JFRTest/jfrPerfTest/build-and-run.log

Command: mvn clean package -Pnative -Dquarkus.version=3.2.5.Final -Dquarkus.native.monitoring=jfr \
-Dquarkus.native.additional-build-args=-H:+UnlockExperimentalVMOptions,-H:+SignalHandlerBasedExecutionSampler,-H:-UnlockExperimentalVMOptions \
-DfinalName=jfr-perf
Command: mvn clean package -Pnative -Dquarkus.version=3.2.5.Final -DfinalName=jfr-plaintext

Command: mvn clean package -Pnative -Dquarkus.version=3.2.5.Final -Dquarkus.native.monitoring=jfr \
-Dquarkus.native.additional-build-args=-H:+UnlockExperimentalVMOptions,-H:+SignalHandlerBasedExecutionSampler,-H:-UnlockExperimentalVMOptions \
-DfinalName=jfr-perf
Command: mvn clean package -Pnative -Dquarkus.version=3.2.5.Final -DfinalName=jfr-plaintext

Do you have a change that mitigates that locally or should I attempt to rearrange the logic?

[roberttoyonaga]

I rarely run local & container at the same time

Ok I see. Even so, it's still doubling the necessary builds (but it's 4 in total instead of 8, when only 2 are necessary).

I can see the app being built twice for the same set of flags too

Yup, this is because jfr-plaintext and jfr-perf are both being built twice for each endpoint (even though both endpoints use the exact same app).

Do you have a change that mitigates that locally or should I attempt to rearrange the logic?

I don't have a change that mitigates it locally, but I'm halfway through a PR that rearranges the build to happen first then get reused for multiple test configurations.

[Karm]

Closed by #212