[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-core-libs-dev
Subject:    Re: RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java
From:       Paul Sandoz <paul.sandoz () oracle ! com>
Date:       2016-01-29 17:21:40
Message-ID: F34DB20C-F52C-49B7-8BA8-5F4A937DB312 () oracle ! com
[Download RAW message or body]


> On 29 Jan 2016, at 17:43, Hamlin Li <huaming.li@oracle.com> wrote:
> 
> 
> 
> On 2016/1/29 20:53, Paul Sandoz wrote:
> > > On 29 Jan 2016, at 13:43, Hamlin Li <huaming.li@oracle.com> wrote:
> > > 
> > > Hi Paul,
> > > 
> > > Sorry for delayed response, have been occupied by other higher priority task.
> > > Thanks for your review, I agree with you that your second approach is better.
> > > New webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.01/
> > > 
> > The changes to the data providers look ok.
> > 
> > Would you mind splitting out the tests between StreamTestData<Integer> and \
> > StreamTestData<Integer>.small as outlined in 2) below. That way for the \
> > non-eplosive stuff we can still crunch on larger data without much of a slow \
> > down.
> Hi Pual,
> 
> Yes, you're right, it does not slow down too much, it cost 15.553 seconds after the \
> first revision(webrev.01), and it cost 16.064 after the second revision(webrev.02). \
> Please check the webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.02/ \
> <http://cr.openjdk.java.net/~mli/8076458/webrev.02/>

+1, reviewed. Do you need me to push it?


> > > Below are times cost for different ops:
> > > total        :169.996
> > > testOps only    :108.988
> > > testIntOps only :23.865
> > > testLongOps only :22.326
> > > testDoubleOps only :16.944
> > > so, I build small data providers for each of them.
> > > 
> > Ok, and i suspect/hope it drops by at least an order of magnitude with your \
> > changes applied.
> Yes, it cost 15.553 seconds after the first revision(webrev.01).

Great.


> > Out of curiosity i wonder what the times would be if using parallel GC rather \
> > than G1.
> With different GC options after second revision(webrev.02):
> -UseParallelGC:  elapsed time (seconds): 16.047
> +UseParallelGC: elapsed time (seconds): 13.263
> -UseG1GC:         elapsed time (seconds): 16.612
> +UseG1GC:        elapsed time (seconds): 16.998
> -UseParallelOldGC: elapsed time (seconds): 16.039
> +UseParallelOldGC: elapsed time (seconds): 14.297
> 

Ok, so i suspect in the case of when your patch is not applied the difference is \
greater in absolute terms and G1 in a sense might be causing such memory intensive \
tests to slow down.

Paul.


[prev in list] [next in list] [prev in thread] [next in thread]