Aexyn / caliper

Automatically exported from code.google.com/p/caliper
Apache License 2.0
0 stars 0 forks source link

Issue with too many GC discards #253

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
the design doc mentions that runs where GC has occurred will be discarded.
this conflicts with runs where GC is inevitable, for example:
"how much does it take to allocate 10m Integer objects"

can this logic be optional?

Original issue reported on code.google.com by o...@yadan.net on 24 May 2013 at 6:15

GoogleCodeExporter commented 9 years ago
GC is "never" inevitable since you can reduce the timing interval, which is 
exactly what we do when making measurements like you describe.  You really 
never want a measurement that included time in GC -- you might as well add 
random.nextDouble() to your results.

Greg, can caliper output a message when too many runs are discarded that 
informs the user how to lower the timing interval?  (Also, do we still need to 
lower the default timing interval to 50-100 ms?)

Original comment by kevinb@google.com on 24 May 2013 at 2:11

GoogleCodeExporter commented 9 years ago
Unless you want to show that your library does not suffer from the same issues 
an existing library is having with GC.
but yeah, this is minor and can easily be shown without an accurate 
microbenchmark tool like Caliper.

Original comment by o...@yadan.net on 25 May 2013 at 7:21