Not worth thinking about until you have fixed the bugs.

Bugs in your DLL.

Well, you've already profiled the Java, haven't you, otherwise you wouldn't
have known that it was worth trying JNI. Then profiling what's going on in
the DLL will probably be useful; and of course you'll have spotted that
calls into a DLL from JNI are really rather expensive, so you've already
made sure that you aren't making very many.

Er, then all the usual speed optimisation steps - look for changes to data
and algorithms before you try to make the existing algorithms run faster (by
coding them in C or whatever). It sounds to me that these two statements of
yours:

could be in conflict. In what sense are your algorithms "good" if they fail
to meet your performance requirements?

--
Tim Ward
Brett Ward Limited - www.brettward.co.uk

First, JNI is no guarantee that your code will run faster, as you have
discovered.

However if you are determined to use JNI, then you need to make sure
your calls to native methods are as few as possible, because crossing
the Java/C boundary to invoke a native method is expensive.

It can be even more expensive to invoke JNI functions from within
native methods (to look up method or field IDs, to set or get values
in Java obects, etc), so make sure any data you pass to and from your
native methods is in a form that can be used directly by the native
method, as far as this is possible.

Slopping pointer handling, failure to manage memory properly,
uninitialized variables, failure to check return values, and things
like that. More information can be found here:

http://c-faq.com/strangeprob/segv.html
http://c-faq.com/strangeprob/funnybugs.html
http://c-faq.com/malloc/crash.html

/gordon

You can't get a 50x speedup "for free" whether by re-writing in C (or Fortran)
or by using a different JVM.  You'd better hope that you are doing something
pretty grossly inefficient, or there is no way that you can fix this (assuming
the algorithms themselves are good, which you say they are, and that using a
farm of a hundred or so computers is not feasible).

Some questions:

Why do you think it is possible at all ?  Do you have a good reason to think
that it's even possible on today's hardware ?   E.g. you may have seen another
application which does roughly the same processing at the speed you desire.

Where is the time going with your current code.  E.g. it could mostly be in the
inner loops of the image processing -- in which case you will have to think
hard about how you can redesign those loops.  But it might be that you are
doing pixel-by-pixel access, and that most of your application's time is spent
reading/writing the values of individual pixels.  Until you know where the time
is going, you have no idea what you have to change.  So profile your code.

Related to the previous question: how is your image data represented while you
are working on it ?  If it isn't an array of primitive numeric values (int[],
float[], byte[], ...) or maybe a small number of such arrays (say, one for each
colour channel), then it should be.

BTW, if you are trying to use JNI, then make sure that you are crossing the
boundary between Java and C as few times as possible.  Once per image per
operation should be about right.  If you are crossing the boundary once per
pixel (or even several times per pixel) then your performance will be dreadful.

Almost certainly a bug in your C code, or in the way you handle JNI.

   -- chris