I’ve made an app using python to talk to a couple of c libraries and it is not too bad. Java was like trace bit the python/c combination was OK. Try finding a c library that does the intensive bit of your app and give the java stuff up. Or try Android which should be a bit faster (though not proper java).
The sun jvm it's pretty much as i said - in the same order, or i.e. on
par with other apps. I compared the gimp to a similar (swing)
application i'm working on as well as a very trivial image viewing
application I whipped up to compare to eog. These are hardly speed
demons but they are real apps that I use daily so i'm familiar with
how they perform.
The image viewer is about the same speed, perhaps sometimes even
faster in absolute load time because it doesn't update incrementally -
but i don't have millisecond timing code in eog so i'm just judging by
eye and cpu usage.
For the graphic editor some things are slower, some are faster but
given various algorithmic and event handling differences it mostly
feels `about the same'. The java stuff uses floating point as an
intermediate operating format for all blending operations, so is
hardly coded for such a machine and could no doubt be improved. But
it seems a valid test of the jit since the blending is all java with
no native optimised code or gl.
For comparison the x86 machine i'm using is approximately 2000x faster
at a specific cpu & memory intensive operation and most operations are
speedier than the gimp - sometimes by a lot. That's also down to
using threads and i presume hardware acceleration.
The shark vm in the openjdk is consistently 1/2 the speed of the sun
embedded one and uses more memory - pushing the image editor from just
barely usable to a real slogfest o pain. So that just isn't there
yet.