[
https://issues.apache.org/jira/browse/CASSANDRA-18871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767525#comment-17767525
]
Stefan Miklosovic commented on CASSANDRA-18871:
-----------------------------------------------
I took a look at the patch and looks fine. Nits were already addressed.
When it comes to IDEA integration like running benchmarks from IDEA directly,
that is just comfortable to have but I do not think that is a strict must.
There is also JMH plugin worth to explore. We explored running of benchmarks
directly from IDEA and it seems to be technically possible but I am questioning
its actual usefulness. If we have a command-line way to run them, is it really
necessary to run them in IDEA too? It is not like we are going to debug them by
putting breakpoints into the benchmark methods. A benchmark is just testing the
performance of the underlying components. If we want to debug that we have a
proper JUnit tests for it. So, for now, this is not a strict requirement for me
to merge this.
When it comes to naming of these tests, why do they have to end on "Bench"?
There is additional logic involved in checking that. What if all benchmarks
were ending on "Test" as all other tests are? It seems to me that the naming
convention for benchmarks was just made up like that but we do not need to
follow it. It would simplify the ant code and stuff around that too. This is
again not a strict requirement for me to merge this.
> JMH benchmark improvements
> --------------------------
>
> Key: CASSANDRA-18871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18871
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Tools
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. CASSANDRA-12586 introduced {{build-jmh}} task which builds uber jar for
> JMH benchmarks which is then not used with {{ant microbench}} task. It is
> used though by the {{test/bin/jmh}} script.
> In fact, I have no idea why we should use uber jar if JMH can perfectly run
> with a regular classpath. Maybe that had something to do with older JMH
> version which was used that time. Building uber jars takes time and is
> annoying. Since it seems to be redundant anyway, I'm going to remove it and
> fix {{test/bin/jmh}} to use a regular classpath.
> 2. I'll add support for async profiler in benchmarks. That is, the
> {{microbench}} target automatically fetches the async profiler binaries and
> adds the necessary args for JMH ({{-prof asyc...}} in particular) whenever we
> run {{microbench-with-profiler}} task. If no additional properties are
> provided some default options will be applied (defined in the script, can be
> negotiated). Otherwise, whatever is passed to the {{profiler.opts}} property
> will be added as profiler options after library path and target directory
> definition.
> 3. If someone wants to see any additional improvements, please comment on the
> ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
