The actual tests are executed many times, I just tried to make a simpler test to be easier to understand.
I executed this code some times to get the average of the result.
Other point:
Executing this code 10 times give different averages of executing the same code in 10 times loop. So the system cache is actually linked to the same JVM instance? At each separated invocation the values keep somewhat constant, differently from one execution with a loop.
I'll try the "select *" approach in the terminal later.
2011/6/13 Craig Ringer
<craig@postnewspapers.com.au>On 13/06/11 11:14, Israel Ben Guilherme Fonseca wrote:
> At every stop, I print the milliseconds occurred between the begin and
> the end of the operation. The results were basically
>
> 1st operation: 0.05 miliseconds
> 2nd operation: 0.1 miliseconds
I suspect you're right on the border of the precision the timers you are
using can offer you. It's hard to be sure as you didn't mention you
platform, CPU, or JDK version.
Try using System.nanoTime() for your timing, and/or (much better) do
many iterations rather than just one to try to smooth out error and jitter.
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/System.html#nanoTime()
> Anyway, that speed increases is definitely a good thing, but why this
> happens it's a mystery for me. The problem is that my benchmark tests
> are influenced with this, cause the order of the tests can influence the
> outcome of the total time.
You really need to tweak your benchmarks to reflect more of a real-world
workload. Timing tiny statements stand-alone will not give you data with
any relationship to what will happen under real load with many such
operations happening concurrently or thousands of them being executed in
rapid sequence.
--
Craig Ringer
