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

Discussion in 'Java' started by zach.lists@gmail.com, Dec 24, 2013.

  1. Guest

    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
     
    , Dec 24, 2013
    #1
    1. Advertising

  2. Eric Sosman Guest

    Re: Question about Pattern.matcher performance differences betweenJava6 and Java7/8

    On 12/24/2013 7:26 AM, 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
    d
     
    Eric Sosman, Dec 24, 2013
    #2
    1. Advertising

  3. Re: Question about Pattern.matcher performance differences between Java6 and Java7/8

    In article <l9c5rb$1kt$>,
    Eric Sosman <> wrote:

    > On 12/24/2013 7:26 AM, 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.
     
    Kevin McMurtrie, Dec 25, 2013
    #3
  4. Stefan Ram Guest

    Re: Question about Pattern.matcher performance differences between Java6 and Java7/8

    Kevin McMurtrie <> 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.
     
    Stefan Ram, Dec 26, 2013
    #4
  5. Re: Question about Pattern.matcher performance differences betweenJava6 and Java7/8

    On 26.12.2013 02:24, Stefan Ram wrote:
    > Kevin McMurtrie <> 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
     
    Robert Klemme, Dec 26, 2013
    #5
  6. Eric Sosman Guest

    Re: Question about Pattern.matcher performance differences betweenJava6 and Java7/8

    On 12/25/2013 2:47 PM, Kevin McMurtrie wrote:
    > In article <l9c5rb$1kt$>,
    > Eric Sosman <> wrote:
    >
    >> On 12/24/2013 7:26 AM, 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
    d
     
    Eric Sosman, Dec 26, 2013
    #6
  7. Re: Question about Pattern.matcher performance differences betweenJava6 and Java7/8

    On 12/25/2013 03:47 PM, Kevin McMurtrie wrote:
    > In article <l9c5rb$1kt$>,
    > Eric Sosman <> wrote:
    >
    >> On 12/24/2013 7:26 AM, 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
     
    Arved Sandstrom, Dec 26, 2013
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. IchBin

    Question on Pattern Matcher?

    IchBin, Jan 1, 2005, in forum: Java
    Replies:
    5
    Views:
    410
    IchBin
    Jan 2, 2005
  2. hiwa
    Replies:
    0
    Views:
    320
  3. Moiristo

    java pattern matcher

    Moiristo, Jul 12, 2006, in forum: Java
    Replies:
    7
    Views:
    2,857
    lordy
    Jul 13, 2006
  4. Stefan Ram
    Replies:
    2
    Views:
    362
    Tom McGlynn
    Jul 11, 2008
  5. Craig Jolicoeur
    Replies:
    9
    Views:
    169
    7stud --
    Apr 29, 2009
Loading...

Share This Page