As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I'm a php developer, but recently had to write the same application twice, once in php and once in java, for a class I'm taking at school. For curiosity I did a benchmark on the two and found that the java version was 2 to 20 times slower than the php version if the database is accessed, and 1 to 10 times slower without DB access. I see two immediate possibilites:
I suck at java.
I can finally tell people to quit whining about php.
I posted my servlet code here. I don't want any nit-picky whining or minor improvements, but can someone see a horrible glaring performance issue in there? Or can anybody explain why Java feels like it has to suck?
I've always heard people say that java is faster and more scalable than php, especially my teacher, he is convinced of it, but the more requests that are made, the slower java gets. php doesn't seem to be affected by increased loads but remains constant.
In a mature Java web application the Servlet would make use of an existing JDBC connection pool. Establishing a new connection will be by far the greatest cost you pay in time.
Calling Class.forName for every attempt to get the connection will also cause an unnecessary slow down.
JVM tuning could also be a factor. In an enterprise environment the JVM memory and possibly GC configurations would be adjusted and tuned to achieve a desirable balance between responsiveness and resource utilization.
As Stephen C points out, the JVM also has a concept of a sort of "warm up".
All that said, I have no idea how PHP compares to Java and I feel both languages offer great solutions to separate non-disjoint sets of needs.
Based on not much info (where the best decisions are made), my guess is the Class.forName("com.mysql.jdbc.Driver"); in getConnection() is the big timesink.
Creating a new String in importFile when the char[] can be passed to out.println is me nitpicking.
Your test seems to reflect initial overhead moreso than steady-state performance. Try doing the non-DB tests multiple times in a loop (so that each test wold run the code multiple times) and look at the linear relationship between runtime and number of iterations. I suspect the incremental cost for java is lower than that for php
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Why does Java have much better performance compared to other interpreted languages like Python? I know this probably has something to do with the fact that it's compiled beforehand, but what about concurrency?
How is the JVM able to perform so much better with concurrent programs, whereas interpreted languages have to do deal with things like global interpreter locking etc, that really slow things down?
This is a really interesting question, but I'm not sure there's a simple way to answer it. JVMs these days use a range of highly aggressive optimizations to try to improve performance. Here are a few:
Dynamic compilation: Most good JVMs can dynamically compile the bytecode directly into machine code, which then executes at native speeds.
Polymorphic inline caching: Many JVMs use inline caching to try to improve the performance of method dispatching by remembering which functions have been called in the past.
Static typing: Since Java is statically-typed, bytecode instructions rarely have to do expensive introspection on the type of an object to determine how to perform an operation on it. Field offsets can be computed statically, and method indices in a virtual function table can be precomputed as well. Contrast this with languages like JavaScript, which don't have static typing and are much harder to interpret.
Garbage collection: The JVM garbage collector is optimized to allocate and deallocate objects efficiently. It uses a combination of mark-and-sweep and stop-and-copy techniques to make most allocations really fast and to make it easy to reclaim lots of memory quickly.
Known choke points: Rather than having a huge VM lock, some JVM implementations automatically insert extra code into each piece of compiled/interpreted code to periodically check in with the VM and determine whether they can keep running. That way, if the JVM needs to do garbage collection in only a few threads, it can do so while the other threads are running. If it needs to do a stop-the-world operation, it will only occur when the threads hit specific points, meaning that simple operations don't have to continuously check in with the VM state.
There are many, many more optimizations in place that I'm probably not aware of, but I hope that this helps you get toward an answer!
Java code has next to no optimisation during compilation.
The runtime JIT does most of the compilation.
What may be different about Java is that it relatively feature poor with minimal side effects. This makes the code easier to optimise.
whereas interpreted languages have to do deal with things like global interpreter locking etc, that really slow things down?
This is an implementation issue. Java was designed with multi-threading support from the start. I suspect python was designed for scripting and rapid development cycles, something it does much better as a result.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Files will ship with bugs, and companies will always want to provide new features. There must
be a way to distribute new files with the hope that the applications will work just fine. And if the application doesn't work fine, there has to be an easy way to restore the application to its last-known good state.
I know this will be general question but I think that is also a general problem.
Comparisons of the solution in different platforms will be amassing.
Dear friends, Actually I am not talking about How to develop software,
Its about How to deploy software with minimum side effects on end users machine
(should be step 0, or -1) use a capable source code management tool, and use it to its full potential: especially branching)
Test Driven Development - always have tests for what you can test, and design code to be testable (to the point it is feasible, of course.)
never do any of these two the same time:
refactoring
introducing new features
fixing a bug
use continuous integration wherever possible
Reverting to "last stable" release in case of emergency
This must be supported by some infrastructural decisions, like keeping around the last stable release compiled and ready to be redeployed if something goes awry despite the efforts (been there, done that)
You should do unit testing. That's a good solution to avoid and track regressions.
But you can't just fast make a change in a big application and build a test unit ensuring everything is OK. You have to make a bunch of test units.
Which is costly, but there is no cheap way to ensure an application is bug free. The only solution is to dedicate a lot of work to testing, be it using unit testing or human testers or both. There's emphasis on that point in Joel Test because a serious team must spend enough in testing.
Restoring an application to an old state is just having a good version control system and not a mess with configuration and data parts. Some VCS have tools to help you find when a bug occured, for example git-bisect.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
To my experience, most of java applications on desktop platforms are less responsive than a similar application written in c++ or some other natively compiled language. Which is understandable considering that java only compiles to intermediate language.
And by responsiveness here I mean the general feel of how the application responds to mouse clicks and keyboard events, the little lags between the user clicking somewhere and the program actually redrawing all the needed things to represent the response to that click. Most often these lags are so small that you don't see them as lag, but you get a feeling that the whole aplication gets a little slow.
Examples of such java applications that I would see as less responsive are Azureus, java-based versions of Zend studio, Eclipse, and a couple of my own swing-based java projects.
Is this really the case? Can a java application ever be as responsive as a native application? Should it perhaps be compiled in some different way? (although you would think that if that was possible, big products such as Zend studio would do that already)
Application responsiveness in Java is frequently down to bad/inefficient programming. While a Java UI is heavier than one written in C/C++, on a recent computer (last few years or so) shouldn't struggle with a well coded application.
Most recent benchmarks show Java 1.6 to be of comparative speed to C/C++ (infact in the last cross language benchmarks I saw it sat snugly between the two in terms of performance).
I think a symptom of Java and the IDEs people use to write it is that it is a forgiving language that lets you do things the wrong way (read, less good way), without complaining too much while C++ would just fall over, forcing you to write better software.
As a personal note, I've seen Java applications where the devs attached a single listener to every element in the UI, then that listener had an enormous if...elseif...elseif... to check the tooltip string that was passed back from the event object.
javac compiles to an intermediate byte code. However the JVM compiles to native code based on how the code is used dynamically (something static compilers cannot do) For GUIs most of the real work is done in native code components so you shouldn't see a real difference.
Many real time trading systems are developed using Java and respond in less than 100 micro-seconds. i.e. 0.0001 seconds. If you have a responsiveness issue, its not the language at fault.
BTW: Eclipse uses SWT which is a native library.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
The JIT compiler has been around for some time. Occasionally it comes to my mind that, "hey, why not just compile Java source file directly to machine code?"
Along with compiled library, we can get rid of the cumbersome JVM.
The only barrier I can think of is the garbage collector. How's your thoughts?
PS: Oh, you say portability? WTH is that? Plus, I'm forced to install a JVM in the first place.
Well, my friend uses Ubuntu, and I use Windows XP, and my other friend uses OSX.
When I send them a jar that I compiled they can both run the file without any changes.
That is why you should not get rid of the JVM.
vm can do complex optimizations based on information only available at runtime. Static compile time optimization simply can't compete. Java is fast because it is running on the vm.
watch this
http://www.infoq.com/presentations/Towards-a-Universal-VM
On some platforms (mostly embedded ones), it's just as you say (or else the machines speak java natively). You can also download compilers that do what you are suggesting, but I imagine you lose a lot of the Java API in the process.
Back to your question, the main reason why is that the people who design the languge and specification want to have it. Plain and simple. It offers portability in the consideration that the "hard" part of making portable code supposedly only has to be done once per environment (another poster spoke of 3 different OS's running the JVM) rather than once per each environment per project. Have you ever tried to make even mostly-portable C++ code without the aid of frameworks like Qt or packages like Boost? It gets VERY difficult, and even then you must still re-compile for each architecture.
Beside portability another issue that comes to mind is dynamic classloading which is difficult to handle via machine code. How would servlet containers work in such a scenario? Maybe it works well for embedded Java, but I don't think for J2EE.
Would the .class form just be an intermediate binary that is converted to machine code before execution? Or would you directly compile from Java source to machine code?
Bytecode generation is necessary for platform independence of code.
JVM (JVM is different for all platforms) reads these bytecode and converts these into machine code depending upon which platform its running. This makes Java compiled code platform independent. JVM also does optimizations which makes Java fast.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
Question about Cassandra
Why the hell on earth would anybody write a database ENGINE in Java ?
I can understand why you would want to have a Java interface, but the engine...
I was under the impression that there's nothing faster than C/C++, and that a database engine shouldn't be any slower than max speed, and certainly not use garbage collection...
Can anybody explain me what possible sense that makes / why Cassandra can be faster than ordinary SQL that runs on C/C++ code ?
Edit:
Sorry for the "Why the hell on earth" part, but it really didn't make any sense to me.
I neglected to consider that a database, unlike the average garden-varitety user programs, needs to be started only once and then runs for a very long time, and probably also as the only program on the server, which self-evidently makes for an important performance difference.
I was more comparing/referencing to a 'disfunctional' (to put it mildly) Java tax program I was using at the time of writing (or rather would have liked to use).
In fact, unlike using Java for tax programs, using Java for writing a dedicated server program makes perfect sense.
What do you mean, C++? Hand coded assembly would be faster if you have a few decades to spare.
I can see a few reasons:
Security: it's easier to write secure software in Java than in C++ (remember the buffer overflows?)
Performance: it's not THAT worse. It's definitely worse at startup, but once the code is up and running, it's not a big thing. Actually, you have to remember an important point here: Java code is continually optimized by the VM, so in some circumstances, it gets faster than C++
Why the hell on earth would anybody write a database ENGINE in JAVA ?
Platform independance is a pretty big factor for servers, because you have a lot more hardware and OS heterogenity than with desktop PCs. Another is security. Not having to worry about buffer overflows means most of the worst kind of security holes are simply impossible.
I was under the impression that
there's nothing faster than C/C++, and
that a database engine shouldn't be
any slower than max speed, and
certainly not use garbage
collection...
Your impression is incorrect. C/C++ is not necessarily faster than Java, and modern garbage collectors have a big part in that because they enable object creation to be incredibly fast.
Don't forget that Java VMs make use of a just-in-time (JIT) engine that perform on-the-fly optimisations to make Java comparable to C++ in terms of speed. Bearing in mind that Java is quite a productive language (despite its naysayers) and portable, together with the JIT optimisation capability, means that Java isn't an unreasonable choice for something like this.
The performance penalty for modern Java runtimes is not that big and programming in Java is less error-prone than in c.