Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Question about Pattern.matcher performance differences between Java6and Java7/8

Reply
Thread Tools

Question about Pattern.matcher performance differences between Java6and Java7/8

 
 
zach.lists@gmail.com
Guest
Posts: n/a
 
      12-24-2013
Hello,

I've noticed a difference in performance between Java6 and Java7/8 (Oracle) on OS X with some toy code. Java6 runs much faster than the updated versions.

VisualVM is pointing me to java.util.regex.Pattern.matcher being the hotspot where all the time is now spent.

I'm still trying to slim down the offending code into a concise example. However I was wondering if anyone knew if there were any changes in java.util.regex.Pattern.matcher performance between Java6 and Java7?

I've read that named groups were introduced in Java7, but I haven't found anything mentioning performance tanking dramatically.

Thanks for any leads you folks may be able to point me to.

-Zach
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      12-24-2013
On 12/24/2013 7:26 AM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hello,
>
> I've noticed a difference in performance between Java6 and Java7/8 (Oracle) on OS X with some toy code. Java6 runs much faster than the updated versions.
>
> VisualVM is pointing me to java.util.regex.Pattern.matcher being the hotspot where all the time is now spent.
>
> I'm still trying to slim down the offending code into a concise example. However I was wondering if anyone knew if there were any changes in java.util.regex.Pattern.matcher performance between Java6 and Java7?
>
> I've read that named groups were introduced in Java7, but I haven't found anything mentioning performance tanking dramatically.
>
> Thanks for any leads you folks may be able to point me to.


One suggestion: Don't fret about the performance of "toy code."

If the performance of "real code" suffers, that's another matter.
Note, though, that if Pattern.matcher() has suddenly become the hot
spot in real code it doesn't necessarily follow that Pattern.matcher()
has become slower. It might instead mean that something else is now
matching a lot more regexes than it used to, or is using a more
complex regex than before. If your car's fuel economy suddenly gets
worse it doesn't prove the engine's gone bad, it may instead have
something to do with the boat trailer you've hitched on ...

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Kevin McMurtrie
Guest
Posts: n/a
 
      12-25-2013
In article <l9c5rb$1kt$(E-Mail Removed)>,
Eric Sosman <(E-Mail Removed)> wrote:

> On 12/24/2013 7:26 AM, (E-Mail Removed) wrote:
> > Hello,
> >
> > I've noticed a difference in performance between Java6 and Java7/8 (Oracle)
> > on OS X with some toy code. Java6 runs much faster than the updated
> > versions.
> >
> > VisualVM is pointing me to java.util.regex.Pattern.matcher being the
> > hotspot where all the time is now spent.
> >
> > I'm still trying to slim down the offending code into a concise example.
> > However I was wondering if anyone knew if there were any changes in
> > java.util.regex.Pattern.matcher performance between Java6 and Java7?
> >
> > I've read that named groups were introduced in Java7, but I haven't found
> > anything mentioning performance tanking dramatically.
> >
> > Thanks for any leads you folks may be able to point me to.

>
> One suggestion: Don't fret about the performance of "toy code."
>
> If the performance of "real code" suffers, that's another matter.
> Note, though, that if Pattern.matcher() has suddenly become the hot
> spot in real code it doesn't necessarily follow that Pattern.matcher()
> has become slower. It might instead mean that something else is now
> matching a lot more regexes than it used to, or is using a more
> complex regex than before. If your car's fuel economy suddenly gets
> worse it doesn't prove the engine's gone bad, it may instead have
> something to do with the boat trailer you've hitched on ...


Note that "real code" is difficult to accurately profile in Java.
Instrumentation causes extremely intrusive de-optimization. Sampling
can only see safepoints, which can be sparse or in odd locations.
Neither can determine real GC load. What ends up happening is that you
pull a chunk of suspect code out of your app and run it by itself in a
controlled environment to benchmark it. The alternative is using a
native profiler and trying to manually correlate CPU instructions with
Java source after HotSpot has moved everything around.


When I benchmark one of my large apps using sampling, Integer.hashCode()
sometimes makes the top ten CPU consumers. The call count is normal and
there's absolutely no code inside Integer.hashCode(). That's just where
HotSpot likes dropping a safepoint in my app.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      12-26-2013
Kevin McMurtrie <(E-Mail Removed)> writes:
>Neither can determine real GC load. What ends up happening is that you
>pull a chunk of suspect code out of your app and run it by itself in a
>controlled environment to benchmark it. The alternative is using a


Sometimes, one wants to compare two versions of suspect code,
one of which has some new »optimization«, to see whether that
optimization helps indeed as much as hoped for.

When one needs to optimize, the application must be observably
slow. That means: macroscopically slow, so slow that one can
measure it using a stop watch or at least detect he slowness
somehow.

In this case, one can compare the two versions in-place. That is:
run the app with the old version and then with the new version.
This will include »real GC load« and all.

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      12-26-2013
On 26.12.2013 02:24, Stefan Ram wrote:
> Kevin McMurtrie <(E-Mail Removed)> writes:
>> Neither can determine real GC load. What ends up happening is that you
>> pull a chunk of suspect code out of your app and run it by itself in a
>> controlled environment to benchmark it. The alternative is using a

>
> Sometimes, one wants to compare two versions of suspect code,
> one of which has some new »optimization«, to see whether that
> optimization helps indeed as much as hoped for.
>
> When one needs to optimize, the application must be observably
> slow. That means: macroscopically slow, so slow that one can
> measure it using a stop watch or at least detect he slowness
> somehow.
>
> In this case, one can compare the two versions in-place. That is:
> run the app with the old version and then with the new version.
> This will include »real GC load« and all.


I'm not sure I agree to the "real GC load": if you artificially slow the
application down to a level where you can use a stop watch you have
already changed behavior dramatically and all bets are off.

Or did you mean it the other way round: you can only apply the stop
watch approach if the application is so slow?

Kind regards

robert


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-26-2013
On 12/25/2013 2:47 PM, Kevin McMurtrie wrote:
> In article <l9c5rb$1kt$(E-Mail Removed)>,
> Eric Sosman <(E-Mail Removed)> wrote:
>
>> On 12/24/2013 7:26 AM, (E-Mail Removed) wrote:
>>> Hello,
>>>
>>> I've noticed a difference in performance between Java6 and Java7/8 (Oracle)
>>> on OS X with some toy code. [...]

>>
>> One suggestion: Don't fret about the performance of "toy code."
>>
>> If the performance of "real code" suffers, that's another matter.
>> [...]

> Note that "real code" is difficult to accurately profile in Java.


So, too, is "toy code."

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      12-26-2013
On 12/25/2013 03:47 PM, Kevin McMurtrie wrote:
> In article <l9c5rb$1kt$(E-Mail Removed)>,
> Eric Sosman <(E-Mail Removed)> wrote:
>
>> On 12/24/2013 7:26 AM, (E-Mail Removed) wrote:
>>> Hello,
>>>
>>> I've noticed a difference in performance between Java6 and Java7/8 (Oracle)
>>> on OS X with some toy code. Java6 runs much faster than the updated
>>> versions.
>>>
>>> VisualVM is pointing me to java.util.regex.Pattern.matcher being the
>>> hotspot where all the time is now spent.
>>>
>>> I'm still trying to slim down the offending code into a concise example.
>>> However I was wondering if anyone knew if there were any changes in
>>> java.util.regex.Pattern.matcher performance between Java6 and Java7?
>>>
>>> I've read that named groups were introduced in Java7, but I haven't found
>>> anything mentioning performance tanking dramatically.
>>>
>>> Thanks for any leads you folks may be able to point me to.

>>
>> One suggestion: Don't fret about the performance of "toy code."
>>
>> If the performance of "real code" suffers, that's another matter.
>> Note, though, that if Pattern.matcher() has suddenly become the hot
>> spot in real code it doesn't necessarily follow that Pattern.matcher()
>> has become slower. It might instead mean that something else is now
>> matching a lot more regexes than it used to, or is using a more
>> complex regex than before. If your car's fuel economy suddenly gets
>> worse it doesn't prove the engine's gone bad, it may instead have
>> something to do with the boat trailer you've hitched on ...

>
> Note that "real code" is difficult to accurately profile in Java.
> Instrumentation causes extremely intrusive de-optimization. Sampling
> can only see safepoints, which can be sparse or in odd locations.
> Neither can determine real GC load. What ends up happening is that you
> pull a chunk of suspect code out of your app and run it by itself in a
> controlled environment to benchmark it. The alternative is using a
> native profiler and trying to manually correlate CPU instructions with
> Java source after HotSpot has moved everything around.
>
>
> When I benchmark one of my large apps using sampling, Integer.hashCode()
> sometimes makes the top ten CPU consumers. The call count is normal and
> there's absolutely no code inside Integer.hashCode(). That's just where
> HotSpot likes dropping a safepoint in my app.
>

My first (and second and third) instinct has been for a long time to use
profilers to get somewhat coarse timing information, and at the same
time to get somewhat coarse function/method usage frequency information.
And not really because of runtime optimizations either; much more
because the last-mile analysis through human code review is most
effective at analyzing performance issues if provided initial data.

AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Issue with regexp pattern matcher withing String#gsub Craig Jolicoeur Ruby 9 04-29-2009 02:57 PM
Re: trying to create a multiple pattern matcher Stefan Ram Java 2 07-11-2008 12:53 AM
java pattern matcher Moiristo Java 7 07-12-2006 11:29 PM
Question on Pattern Matcher? IchBin Java 5 01-02-2005 07:02 PM
Question on Pattern Matcher? hiwa Java 0 01-02-2005 09:43 AM



Advertisments