FULL PRODUCT VERSION :
applies to all there:

java version "1.6.0-beta2-fastdebug"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-fastdebug-b84)
Java HotSpot(TM) Server VM (build 1.6.0-beta2-fastdebug-b84-debug, mixed mode)

java version "1.6.0-beta2-fastdebug"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-fastdebug-b84)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-fastdebug-b84-debug, mixed mode)

java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Athlon64 X2 4400+ with /usepmtimer in boot.ini

A DESCRIPTION OF THE PROBLEM :
System.nanoTime() is more then 25x times slower then System.currentTimeMillis().

If I use nanoTime() for benchmarking it slows down my application by a huge factor.
If I use currentTimeMillis() then I don't have enough time precision.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the test case

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
nanoTime: 169 ns
currentTimeMillis: 57 ns

ACTUAL -
nanoTime: 1659 ns
currentTimeMillis: 57 ns


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class PerfTest {
    private static final int COUNT = 1000000;
    public static void main(String[] args) {
        long start = System.nanoTime();
        long end = start;
        for(int i=0 ; i<COUNT ; i++) {
            end = System.nanoTime();
        }
        System.out.println("nanoTime: " + (end-start) / COUNT + " ns");
        
        long dummy = 0;
        start = System.nanoTime();
        for(int i=0 ; i<COUNT ; i++) {
            dummy = System.currentTimeMillis();
        }
        end = System.nanoTime();
        System.out.println("currentTimeMillis: " + (end-start) / COUNT + " ns");
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use a JNI DLL which uses the processor counter (RDTSC) and normalize the counter after the measurement - but this has then JNI overhead which is not the case for currentTimeMillis() because it is inlined by the JVM.