Partial RE for Benchmark Tests

[Aleksey Shipilev]

Okay, let's see how that turns out.

I think this is your entry point:

http://hg.openjdk.java.net/code-tools/jmh/file/e739c4bf5798/jmh-core/src/main/java/org/openjdk/jmh/runner/BenchmarkList.java#l95

We would also need a few new unit tests against BenchmarkList here:
 http://hg.openjdk.java.net/code-tools/jmh/file/e739c4bf5798/jmh-core/src/test/java/org/openjdk/jmh/runner/TestBenchmarkList.java

Thanks,
-Aleksey.

P.S. I see your OCA from Seeburger (b_eckenfels), would you use that? We
would need the mail with the patch to originate from the address
supplied in your OCA.

On 08/12/2014 03:40 AM, Bernd Eckenfels wrote:
> Hello Aleksey,
> 
> I think from the point of implementing, it is enough to use
> Matcher.find() instead of matches().
> 
> It will find substrings/patterns unless you anchor them forcefully with
> "^" or "$". This is typical behaviour for grep:
> 
> bash-3.1$ echo "abcd" | grep "^.*b.*$"
> abcd
> bash-3.1$ echo "abcd" | grep "^.*b$"
> bash-3.1$ echo "abcd" | grep "^.*d$"
> abcd
> bash-3.1$ echo "abcd" | grep "c"
> abcd
> 
> Gruss
> Bernd
> 
> 
>  Am Tue, 12 Aug 2014 03:17:08 +0400
> schrieb Aleksey Shipilev <aleksey.shipilev at oracle.com>:
> 
>> Hi Bernd,
>>
>> On 08/12/2014 02:45 AM, Bernd Eckenfels wrote:
>>> JMH uses a regular expression to select the Benchmarks. While doing
>>> so (as I understand it) it reuqires a full match. This has the
>>> "disadvantage" that you always need to specify ".*MyBenchmark.*".
>>> Not everybody is used to this syntax and it is really seldomly
>>> needed.
>>>
>>> How about changing this to a partial match with ^$ support: if you
>>> specify an expression and it is found inside the benchmark name, the
>>> benchmark will be selected. That way you can even specify Substrings
>>> and be done 99% of the time: MyBenchmark. If you need to be more
>>> speficic, you could: "^.*MyBenchmark\.[^.]+"
>>>
>>> Is it worth coming up with a patch for it?
>>
>> This is an interesting idea, but we need to think through what exactly
>> do we want: more use-cases, including the corner cases? Is there a
>> reference to what other regexp-accepting products do?
>>
>> Your suggestion seems to amount to:
>>  1) Look for an explicit "^" at the beginning, add ".*" at the
>> beginning, otherwise.
>>  2) Look for an explicit "$" at the end, add ".*" at the end,
>> otherwise.
>>
>> Thanks,
>> -Aleksey.
>>
>>
>