native method performance puzzle

Discussion in 'Java' started by arne thormodsen, May 15, 2008.

  1. 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
     
    arne thormodsen, May 15, 2008
    #1
    1. Advertising

  2. arne thormodsen

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, May 15, 2008
    #2
    1. Advertising

  3. In article <g0g133$v5t$>,
    "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.
    >
    > 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.
     
    Kevin McMurtrie, May 15, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jabel D. Morales - VMan of Mana

    Problems with JNI: calling a Java method from native method.

    Jabel D. Morales - VMan of Mana, Aug 1, 2003, in forum: Java
    Replies:
    1
    Views:
    4,782
    Joseph Millar
    Aug 1, 2003
  2. noone
    Replies:
    1
    Views:
    501
    Thomas Hawtin
    Mar 5, 2006
  3. Twisted
    Replies:
    31
    Views:
    1,789
    Roedy Green
    Mar 23, 2006
  4. Blackie
    Replies:
    2
    Views:
    74
    Ari Brown
    Oct 19, 2007
  5. Ma Sa
    Replies:
    15
    Views:
    192
    Lionel Bouton
    Mar 6, 2008
Loading...

Share This Page