native method performance puzzle

java-programmer, native method performance puzzle Just to be clear, I'm afraid that I can't do more than sketch my problem out
here, since it's customer-specific, but I'm hoping for some direction.

I'm testing two implementations of a data-processing API, one in pure Java,
one in native methods (windows dll). The process I am testing is disk I/O
intensive.

Running the same performance test over and over again I've found that the
pure Java implementation gives very consistent results, while the native
method version gives results that steadily get better over about a dozen
runs, finally ending up about the same at the pure Java implementation
(probably ultimately limited by disk thruput).

For example, test 1 might look like:

pure Java method : 12 sec
native method: 20 sec

test 5 like:

pure Java method: 11 sec
native method: 15 sec

test 10 like:

pure Java method: 12 sec
native method: 10 sec

What could be going on here? It sure feels like something is being cached,
but I'm not sure what.

Thanks,

--arne

java-programmer >> native method performance puzzle arne thormodsen wrote:
> Just to be clear, I'm afraid that I can't do more than sketch my problem out
> here, since it's customer-specific, but I'm hoping for some direction.
>
> I'm testing two implementations of a data-processing API, one in pure Java,
> one in native methods (windows dll). The process I am testing is disk I/O
> intensive.
>
> Running the same performance test over and over again I've found that the
> pure Java implementation gives very consistent results, while the native
> method version gives results that steadily get better over about a dozen
> runs, finally ending up about the same at the pure Java implementation
> (probably ultimately limited by disk thruput).
>
> For example, test 1 might look like:
>
> pure Java method : 12 sec
> native method: 20 sec
>
> test 5 like:
>
> pure Java method: 11 sec
> native method: 15 sec
>
> test 10 like:
>
> pure Java method: 12 sec
> native method: 10 sec
>
> What could be going on here? It sure feels like something is being cached,
> but I'm not sure what.

no code => pure guessing

My guess would be that the Java code uses its own cache while the native
code relies on the OS cache.

Arne

java-programmer >> native method performance puzzle In article <g0g133$v5t$email***@***.com>,
"arne thormodsen" <email***@***.com> wrote:

> Just to be clear, I'm afraid that I can't do more than sketch my problem out
> here, since it's customer-specific, but I'm hoping for some direction.
>
> I'm testing two implementations of a data-processing API, one in pure Java,
> one in native methods (windows dll). The process I am testing is disk I/O
> intensive.
>
> Running the same performance test over and over again I've found that the
> pure Java implementation gives very consistent results, while the native
> method version gives results that steadily get better over about a dozen
> runs, finally ending up about the same at the pure Java implementation
> (probably ultimately limited by disk thruput).
>
> For example, test 1 might look like:
>
> pure Java method : 12 sec
> native method: 20 sec
>
> test 5 like:
>
> pure Java method: 11 sec
> native method: 15 sec
>
> test 10 like:
>
> pure Java method: 12 sec
> native method: 10 sec
>
> What could be going on here? It sure feels like something is being cached,
> but I'm not sure what.
>
> Thanks,
>
> --arne

There's a lot going on behind the scenes of both Java and a
native-compiled language. Both of them intercept generic calls to the
system APIs to standardize the environment and perform optimizations.
Memory allocation and file access are common targets. In this case,
Java may be outperforming what your native compiler is doing. An
outdated native compiler can destroy your code's performance with
optimizations that don't scale to modern needs. A native debugger can
help you discover what's going on.

--
Block Google's spam and enjoy Usenet again.
Reply with Google and I won't hear from you.