Need to recompile a Java Applet as an Executable
in [Java Programming]
|
Prev: How to get an include-path of jni.h that is able to be differenton different platforms.
Next: Read utf-8 file return utf-16 coding hex string ?
From: Arne Vajhøj on 30 Jan 2010 22:46 On 29-01-2010 06:33, Sanny wrote: >> Sanny wrote: >>> I have a Java Applet which is quite slow. >> >>> There are a few functions that are called by the Java Applet. I want >>> those functions to be run as fast as possible. >> >> You should probably fix your Java code then. It's rare for Java >> performance to be so critical that you need to go outside of Java. And >> you almost certainly won't get the 10x or 20x speedup you seem to be >> hoping for. > > There is nothing wrong with the java code. I know some expressions in > C are working 10-20 times faster. If you expect x10-20, then there is definitely something wrong with your Java skills and therefore most likely something wrong with your Java code as well. > Also I can configure Compilation in "C" such that it do not do error > checking at runtime speeding it up further. That sounds more like Ada than like C. > My program does a lot of array sorting and array search and > comparisions. That is quite faster in C. Also lot of String Operation > is done. > > In Java String Operations are 100 times slower than in "C". As copying > a string takes lots of time in Java. Array work can be faster in C than in Java. String operations are typical slower in C than in Java. So you are basing your design on some very bad assumptions. >>> One Option is to use Native Support. >> >> You can easily make things slower, if you do that wrong. And it won't >> necessarily be faster in any case. IMHO JNI is more appropriate for >> when you need some specific functionality that's simply not available in >> Java, or you need to reuse some code that would be impractical to port >> to Java. >> >> No doubt there are some specific, very specialized applications in which >> writing some custom native code and calling it via JNI is helpful. But >> statistically speaking, it's not likely your program is in that category. > > One more reasion to use "C" is to have my code encrypted. Java Code is > available to all so others can easily hack the java code. While > cracking an Activex is I suppose impossible. You can obfuscate the Java code, but even obfuscated Java byte code is a lot easier to reverse engineer than native executable. So it is definitely a valid argument for native code. But given your level of Java skills, then I don't think there is any risk for you. >>> Does an Applet support native language? >> >>> Can I create a C++ / C function and ask the applet to call that C >>> function that is run on Users Computer? And get back the output and >>> display on the Applet? >> >> Unfortunately, I don't know much about applets. But due to security >> concerns, I would expect applets to have much more restricted access to >> JNI than regular Java applications. > > I have full understanding of these. Only problem is how Browser > accepts the Activex and Applet. > > Will a firefox browser run an ActiveX on Non Windows OS? No. And not on Windows either. Arne
From: Arne Vajhøj on 30 Jan 2010 22:47 On 29-01-2010 14:31, Antoninus Twink wrote: > On 29 Jan 2010 at 8:01, Nick Keighley wrote: >> this isn't on topic on comp.lang.c how C or C++ "links" with java is >> outside the scope of the C or C++ language. > > Utter nonsense. No. JNI is defined by Java not by C. And that includes both Java calling C and C calling Java. Arne
From: Arne Vajhøj on 30 Jan 2010 22:51 On 29-01-2010 17:17, Antoninus Twink wrote: > On 29 Jan 2010 at 21:42, BGB / cr88192 wrote: >> anyways, assuming that the browser is not using a poor JVM >> implementation (a plain interpreter or similar), Java vs C performance >> is not likely to be significant enough to bother worrying about in >> this case, and one is instead better off concerning themselves with >> writing efficient code (any language will be slow if the programmer >> doesn't know what they are doing, and usually the language/compiler is >> the first thing to be blamed for the poor performance of badly written >> SW). > > To be honest, whatever stories people come up with about how good their > JIT compiler is at optimizing on the fly and such like, the truth is > that for many applications, rewriting the bottleneck in C will gain you > an order of magnitude. > > I believe the principal two reasons for this are: > > 1) No overhead in basic data types. AIUI, Java will take many bytes to > store a simple int, just because of all the OO book-keeping that needs > to accompany every single object. Therefore, smaller slices of every > array can fit in cache ---> performance death. I think we can stop reading here. Anyone that has read "Java for absolute beginners" know that int's in Java are not objects and use the exact same number of bytes as C (on platforms where C int is 4 byte). If you don't like Java, then by all means avoid coding in it, reading about it or even think about it. But why post to usenet about something you have not studied???? Arne
From: Arne Vajhøj on 30 Jan 2010 23:07 On 30-01-2010 01:23, Richard Heathfield wrote: > BGB / cr88192 wrote: >> actually, for the simple tool I converted, about the only real >> noticable differences was that the C++/CLI version took around maybe >> 100-250 ms longer > > Perhaps .Net has improved in recent years, then. When I tried this, > about six or seven years ago (with the original intent of putting the > program into production), it was 50-60 times slower than C (admittedly > for a heavily recursive application). That is not in any way typical. It is completely off the scale for unlikelihood. But if I remember correct from last time you gave the story, then you can not explain exactly what the code did. So we can not explain why it was so. We can just tell you that it is not what you usually see. Arne
From: Richard Heathfield on 31 Jan 2010 02:43
Arne Vajh�j wrote: > On 30-01-2010 01:23, Richard Heathfield wrote: >> BGB / cr88192 wrote: >>> actually, for the simple tool I converted, about the only real >>> noticable differences was that the C++/CLI version took around maybe >>> 100-250 ms longer >> >> Perhaps .Net has improved in recent years, then. When I tried this, >> about six or seven years ago (with the original intent of putting the >> program into production), it was 50-60 times slower than C (admittedly >> for a heavily recursive application). > > That is not in any way typical. I can accept that, not having any further data with which to contradict you. > It is completely off the scale for unlikelihood. Fine, but I was there, and I know what I saw. > But if I remember correct from last time you gave > the story, then you can not explain exactly what the > code did. Well, "exactly" would take too long and may conceivably breach customer confidentiality - and in any case it was so long ago that I've possibly forgotten some important details. But roughly, we were writing elementary language parsers - not because we find wheel reinvention particularly exciting, but because we wanted to be able to extract such dependency information as existed within source code. For example, if foo.c #included "nice/handy/path/info/foo.h" or fopened "zog.dat", or if bar.html contained <a href="baz.html">, then we wanted to know. And if baz.html in turn contained <a href="quux.asp">, then we wanted to know that, too - recursively, for each dependency for which the source was available. We wrote parsers for a number of programming and markup languages - not fullblown parsers, just enough to get what we needed - in C++. Clearly these parsers were heavily recursive, which may explain why the .Net version was so slow. We didn't test on .Net for the hell of it, but because we were instructed by the client to move our code to the brand-new just-released ..Net platform. Since we'd written our code with portability in mind, this wasn't difficult. At this point we re-tested. It was at this point that we discovered the massive performance hit. (It was so massive that we had to test twice - the first time, we stopped the test because we just sort of assumed it had crashed. But it probably hadn't.) > So we can not explain why it was so. Neither can I. > We can just tell you that it is not what you usually see. Assuming "you" is meant generically, I have no problem believing that. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within |