[jira] [Commented] (TAP5-2839) Add JMH benchmarking

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-2839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125805#comment-18125805 ] 

ASF subversion and git services commented on TAP5-2839:
-------------------------------------------------------

Commit 0552a26bb88695984dcf9c5f92966e629f9788a4 in tapestry-5's branch refs/heads/master from Ben Weidig
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=0552a26bb ]

TAP5-2839: Introduce JMH (#69)

Adds JMH as a new Gradle convention and also a few sensible baseline benchmarks for things I might want to work on in the future.

Renamed the IntegrationTestMutex to be reusable for JMH, as it also doesn't like running in parallel.

> Add JMH benchmarking
> --------------------
>
>                 Key: TAP5-2839
>                 URL: https://issues.apache.org/jira/browse/TAP5-2839
>             Project: Tapestry 5
>          Issue Type: Improvement
>    Affects Versions: 5.10.0
>            Reporter: Ben Weidig
>            Assignee: Ben Weidig
>            Priority: Minor
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Performance changes in Tapestry aren't currently measurable, at least not in a deterministic fashion.
> There is no way to state what a change to the IoC registry, a coercion, or the DOM rendering actually costs based on hard numbers.
> h4. Proposal
> Introduce [JMH|https://github.com/openjdk/jmh] as a Gradle convention plugin ({{tapestry.jmh-convention}}), so any module can carry microbenchmarks in {{src/jmh/java}}.
> * JMH {{1.37}}, declared in the version catalog
> * Benchmark source set compiles against the module's own classes and its {{provided}} configuration, mirroring the test source set
> * Two tasks per module: {{jmh}} (run) and {{jmhList}} (list without running)
> * Run options as {{-P}} properties: {{jmh.include}}, {{jmh.exclude}}, {{jmh.quick}}, {{jmh.forks}}, {{jmh.profilers}}, {{jmh.resultFile}}, and others
> * Results are written as JSON, so a before/after pair can be diffed, and easier visualized
> h4. CI
> Benchmarks are deliberately *not* wired into {{check}} or {{build}}.
> A JMH run can take minutes or even longer, and has therefore no place in CI.
> The root task {{jmhCompileAll}} compiles every benchmark source set instead, so refactorings cannot break them silently.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)