|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 55
Messages: 55
Messages: 55
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Java is Slow! - A Cautionary Tale
Here is a cautionary tale for those who claim that "Java is too slow!" We all know the type. This is also a cautionary tale against those clueless "engineers" who reinvent the wheel (e.g. hand-coding DB4O and threads messaging instead of using ActiveMQ/JMS) with a kludge because "they want to see the data" and don't trust Java best practices.
From the article:"You're a developer, not a hacker," Dick ranted after being shown the Java prototype, "we already have the right tools for the job at our hands. Anything that must be run as bytecode through a virtual machine will always be ten times slower!"
...
"Dick insisted that, if we were to interface with your system, then we'd have to write everything to text files for reliability. He likes to have the data around where he can see it. To the best that we can tell, he just didn't trust the whole Java and database thing." Beware of the clueless or inexperienced C/C++/Perl dabbler in your midst!
|
|
|
Message #308779
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
Here is a cautionary tale for those who claim that "Java is too slow!" We all know the type. This is also a cautionary tale against those clueless "engineers" who reinvent the wheel (e.g. hand-coding DB4O and threads messaging instead of using ActiveMQ/JMS) with a kludge because "they want to see the data" and don't trust Java best practices.
From the article:"You're a developer, not a hacker," Dick ranted after being shown the Java prototype, "we already have the right tools for the job at our hands. Anything that must be run as bytecode through a virtual machine will always be ten times slower!"
...
"Dick insisted that, if we were to interface with your system, then we'd have to write everything to text files for reliability. He likes to have the data around where he can see it. To the best that we can tell, he just didn't trust the whole Java and database thing." Beware of the clueless or inexperienced C/C++/Perl dabbler in your midst!
Man, this so much reminded me of my first job fresh out of university when I worked as a programmer at a Microsoft Shop. My supervisor was similar to Dick, and he was the company's senior programmer, but he always insisted on doing things from scratch in C, even though I tried to convince management and him that C was not ideal for everything and it often led to programmers re-inventing the wheel for many common problems which unlike the java tech space, there were many things already built for which you just plug them into your app and go. But the usual response was that Java was too slow (i.e. byte code execution), and seeing that he was the senior programmer, our old school management team always went with his call.
I can't begin to tell you how painful it was for me to end up building medium to large scale client server apps in C and Visual Basic. And don't even talk about the size and severity of the bug lists - remember, things were usually built from the ground up, including security.
I had to leave the company to save my sanity - been happy ever since in Java land.
|
|
|
Message #308781
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Yes. Java is too slow
Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language. I'm talking about just the language and platform. Not frameworks/open source efforts. Closures anyone?
The way Java 7 is going, it isn't too re-assuring.
|
|
|
Message #308784
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
I was just reading a post on a forum from someone who wrote an XML parser in RPG because the XML package they have "works, but it is S---L---O---W. (It's written in Java.)"
Of course there are plenty of Java programmers that think WS* is the only web-service technology going. It's quite easy to become "Dick".
|
|
|
Message #308785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Yes. Java is too slow
Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language. I'm talking about just the language and platform. Not frameworks/open source efforts. Closures anyone?
The way Java 7 is going, it isn't too re-assuring.
This is Java's MO. There are plenty of languages that add features faster than you can keep up with them. In some ways this is it's strength. A lot of languages burn-out and become unpopular because of the weight of all the features they have.
|
|
|
Message #308788
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Yes. Java is too slow
Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language. I'm talking about just the language and platform. Not frameworks/open source efforts. Closures anyone?
The way Java 7 is going, it isn't too re-assuring.
This is Java's MO. There are plenty of languages that add features faster than you can keep up with them. In some ways this is it's strength. A lot of languages burn-out and become unpopular because of the weight of all the features they have.
Man, you are taking the words out of my mouth.
Some degree of innovation is good, but going too fast is never that good. Let just think that many house are still using 1.4; (there might even be some stuck in 1.3). Pacing the innovation race allow those trailing houses to catch up. Waiting for everybody to reach a good maturity level on 1.5/1.6 can only lead to a stronger adoption of 1.7 when the majority will be ready (IMHO). On the other hand, going too far too fast without waiting for those trailing houses to catch up a little bit will only lead to more resistance (IMHO again).
ZC.
|
|
|
Message #308789
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Slower Than RPG for Parsing XML ?
I will take a leap of logic and assume this is an AS/400 platform, on account of the use of RPG. To my chagrin, I know a bit about Java on the AS/400 and it's typical [mis]use on that platform. Part of the problem is that the JVM startup time is huge. The AS/400 has its own "native" byte code optimizer which can invoked from QShell or through the excellent JTOpen java class library. This makes a pretty big difference, but I have observed it is rarely used.
More to the point, java is frequently used for one time invocations and I would say with 75% certainty that your RPG enthusiast friend was calling a new instance of a JVM to parse each XML fragment rather than the prescribed architecture of keeping a JVM running all the time and passing tasks to it. Virtually any byte code oriented virtual machine will perform poorly when used in this way.
We actually run a JBoss application server on the AS/400 and once it fires up, it performs quite well, including XML parsing.
I should also point out that OS/400 has been shipping with an RPG based XML parser for some time, and while I have heard it is cumbersome to use, it is quite performant and makes me pause to wonder why your RPG enthusiast friend would write his own parser when already being in possession of two provided by IBM. I am sure there was a good reason, however.
|
|
|
Message #308790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
I was just reading a post on a forum from someone who wrote an XML parser in RPG because the XML package they have "works, but it is S---L---O---W. (It's written in Java.)"
Of course there are plenty of Java programmers that think WS* is the only web-service technology going. It's quite easy to become "Dick".
And it didn't occur to you before you made this post that maybe that Java XML parser implementation may not have been optimal or maybe the person who was having the problem with that Java XML parser could have tried another one from the multitude of available Java parsers?
You see, the deeper point behind the story of Dick and Pete, is that people like Dick normally do unnecessary programming activities, not directly related to the implementation of the business requirements, because they usually want to draw attention to themselves from management that they are the greatest thing in their organization aside from the mail server - i.e., doing Wylie Coyote style programming where they code both the application infrastructure code (e.g. their own custom application server, database servers, etc.) along with coding the actual business process aspects of the overall system. Rather than trusting the maturity or wide scale adoption of third party code or sub systems, they instinctively jump to building themselves what's already available .
Modern software development practices, usually encourages you not to repeat yourself, or not to re-invent the wheel, unless you absolutely have to - meaning that you do the due diligence in googling around the web for someone or some company that has already built what you're looking for.
Building an RPG XML parser sounds really Dickish to me. lol.
|
|
|
Message #308791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
OMG!! Please oh please, somebody tell me that peoples like this dick don't exists anymore.
This is an actualized tale of the 1960's isn't it ?
ZC.
|
|
|
Message #308792
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Slower Than RPG for Parsing XML ?
I will take a leap of logic and assume this is an AS/400 platform, on account of the use of RPG. To my chagrin, I know a bit about Java on the AS/400 and it's typical [mis]use on that platform. Part of the problem is that the JVM startup time is huge. The AS/400 has its own "native" byte code optimizer which can invoked from QShell or through the excellent JTOpen java class library. This makes a pretty big difference, but I have observed it is rarely used.
I do some work on the 400 and in current versions the optimizer runs automatically. I think not at the highest level but I've seen some things that suggest to me that the 40 level optimization is buggy (or was.)
The bigges performance problems I've had with the 400 have had to do with a misconfigured memory pools that forced the application to thrash wildly on even smallish (30 MB) heaps. I've also found that doing a lot of IO to the IFS (e.g. trace logging) causes similar behaviors.
|
|
|
Message #308793
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
And it didn't occur to you before you made this post that maybe that Java XML parser implementation may not have been optimal or maybe the person who was having the problem with that Java XML parser could have tried another one from the multitude of available Java parsers?
Why would you think it didn't occur to me? That seems like a pretty stupid assumption.
I expect that it was slow. It was the assumption that the reason was because it was written in Java. I actually suggested that he look at the setup on the system and that there are many ways tools to parse XML in Java.
|
|
|
Message #308794
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java Slower Than RPG for Parsing XML ?
To my chagrin, I know a bit about Java on the AS/400 and it's typical [mis]use on that platform. Part of the problem is that the JVM startup time is huge.
I forgot to say that my experience is that the VM startup time (after the initial run) is not much more than I see in other environments. It matters if you submit the job or run it interactively but once I learned about the memory pools and not to do too much IO to the IFS, things run just fine. It's a challenging environment to run Java in to be sure partly because it's so hard to get any information. IBM's documentation is next to worthless.
Maybe we should start a Java/400 forum somewhere.
|
|
|
Message #308795
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
If you are working for Real time/missile application, you may have to consider 1/10000 of the second. Most of the enterprise application needs faster response, however it doesn't mean/count 1/10000 of the second. So even if java runs slower it should be okay. Many times you don't have to re-invent the wheel. I do know the pain of writing each and every functionality on your own. In the Java land, most of them are already available, all we need to integrate it well.
|
|
|
Message #308796
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
And it didn't occur to you before you made this post that maybe that Java XML parser implementation may not have been optimal or maybe the person who was having the problem with that Java XML parser could have tried another one from the multitude of available Java parsers?
Why would you think it didn't occur to me? That seems like a pretty stupid assumption.
I expect that it was slow. It was the assumption that the reason was because it was written in Java. I actually suggested that he look at the setup on the system and that there are many ways tools to parse XML in Java.
You're all over the place here man. Why didn't you post this later part of your explanation in your first post? Your first post left the impression that the one Java XML parser that the dude was having a problem with led him to create an XML parser in RPG because Java is slow. Now you're saying in this post that you gave the dude suggestions on looking at system setup, and other tools to parse XML in Java.
What are you really trying to communicate, or do you think the readers of your posts are psychic and can tell what you really want to say in your posts despite the information gaps, or that we can tell what you're going to say in your followup posts?
Either way your posts seem confusing dude. Just read them over for yourself in the sequence written, and see for yourself.
|
|
|
Message #308798
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
You're all over the place here man. Why didn't you post this later part of your explanation in your first post? Your first post left the impression that the one Java XML parser that the dude was having a problem with led him to create an XML parser in RPG because Java is slow.
That's what he wrote (hence the quotation marks.) What's confusing about that?
Now you're saying in this post that you gave the dude suggestions on looking at system setup, and other tools to parse XML in Java.
How is that inconsistent with the above? He wrote that "Java is slow" I responded that Java isn't slow. Just because a given Java application is slow doesn't mean the language is the reason. What part of this are you struggling to understand?
What are you really trying to communicate, or do you think the readers of your posts are psychic
The irony here is that you appear to think you are psychic.
and can tell what you really want to say in your posts despite the information gaps, or that we can tell what you're going to say in your followup posts?
Either way your posts seem confusing dude. Just read them over for yourself in the sequence written, and see for yourself.
I think you have a problem with reading comprehension. And if you are going to respond to someone with unprovoked snarkiness, I suggest you first get your shit correct.
|
|
|
Message #308797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Too slow, perhaps
While there is value in stability, there is also value in evolution, particularly toward some long-term goal. The Java programming language has nobody responsible for planning its evolution. The changes being considered for Java 7 are one-off, mainly unrelated features with little strategic value. There is no benevolent dictator for Java, and the Java ecosystem suffers as a result.
|
|
|
Message #308800
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Too slow, perhaps
While there is value in stability, there is also value in evolution, particularly toward some long-term goal. The Java programming language has nobody responsible for planning its evolution. The changes being considered for Java 7 are one-off, mainly unrelated features with little strategic value. There is no benevolent dictator for Java, and the Java ecosystem suffers as a result.
I don't disagree with that but the point is that if Java were a language that was constantly adding features, I imagine a lot less people would be using it. What I mean is that a lot of the developers 'forced' to use Java wish it would get their favorite features but if it were the kind of language that had everyone's favorite features, they wouldn't be 'forced' to use it. They'd likely be bitching about a different slowly changing language.
On the subject of Benevolent Dictators, I like Python but it's being ripped down to the studs to clear out all the garbage that's been added over the years, I think it's a pretty decent illustration of trade-offs in question. Not that Java's perfect or anythin, not by a long shot.
The upshot is that IMO, it's not such a bad thing to have different languages with different strategies for change.
|
|
|
Message #308801
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
You're all over the place here man. Why didn't you post this later part of your explanation in your first post? Your first post left the impression that the one Java XML parser that the dude was having a problem with led him to create an XML parser in RPG because Java is slow.
That's what he wrote (hence the quotation marks.) What's confusing about that?
Now you're saying in this post that you gave the dude suggestions on looking at system setup, and other tools to parse XML in Java.
How is that inconsistent with the above? He wrote that "Java is slow" I responded that Java isn't slow. Just because a given Java application is slow doesn't mean the language is the reason. What part of this are you struggling to understand?
What are you really trying to communicate, or do you think the readers of your posts are psychic
The irony here is that you appear to think you are psychic.
and can tell what you really want to say in your posts despite the information gaps, or that we can tell what you're going to say in your followup posts?
Either way your posts seem confusing dude. Just read them over for yourself in the sequence written, and see for yourself.
I think you have a problem with reading comprehension. And if you are going to respond to someone with unprovoked snarkiness, I suggest you first get your shit correct.
@J Watson
So I see that you didn't take my advice to read through your posts to review the confusing aspects of it, particularly the first one and the original impression it seemed to bring across that the dude was justified to go and write his own RPG XML parser. Instead you're allowing your ego to cloud the rational part of your brain by instead concentrating your energies on flaming, and backtracking to save face, after I raised the matter of your confusing second and first posts. You should know that what you wrote is still there right?
Go ahead man, whatever creams your coffee. I'm done with telling you. I'm guessing here that you didn't get the meaning of the story of Dick and Pete or even understand the title of the article. But that's ok, give it a day or two to settle in. lol.
|
|
|
Message #308836
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
So I see that you didn't take my advice to read through your posts to review the confusing aspects of it, particularly the first one and the original impression it seemed to bring across that the dude was justified to go and write his own RPG XML parser.
That's in your head. It has nothing to do with what I wrote. I never intended to suggest that nor is there anything in what I wrote that does.
|
|
|
Message #308838
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
java is slow
sun sold java to oracle , when it became evident - java cannot compete with new languages.
|
|
|
Message #308839
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: java is slow
sun sold java to oracle , when it became evident - java cannot compete with new languages.
Hmm, I am not sure if I got this wrong or you, but wasn't Sun sold to Oracle as a whole and not just Java, and as a consequence Java also changed hands to Oracle.
However, if you believe some "internal sources", Oracle actually bought Sun *because* of Java since it considers it it's greatest asset, besides it huge customer base in financial services and government and its brand.
Just my 2 cents...
But, back to the original topic:
There are actually some benchmarks showing that these days a well written Java application on a modern JVM and OS can perform better than a native, speak C/C++, application. So, this tells me that
a) Java and its performance has come a long way, and
b) Java is definitely not slow!
|
|
|
Message #308845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
Your exemple of JMS is bad. We started using JMS... And it was infact far too slow.
We tried many implementations etc.
Then we went to simple TCP/IP (in java) and i was realy realy faster.
And for our need, most of JMS was not necessary at all and need yet another server to manage it.
At the beginning the client wanted message to be encoded in XML (with more than 20K message to send and receive per second)... Again it's was too slow and we then used Java Serialization.
It's true java is slow, but using the right tool, even in JAVA is really important. For most IT needs, java is simply a good choice.
If you need fine control of performance and low level concerns, instant responce and thing alike just go C/C++... But only if it's really needed.
|
|
|
Message #308846
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Don't whine about Java being slow
This has been an age-long (at least 10 years) complaint about Java and I have found in these 10 years that it's a load of bull****.
I have implemented a number of highly transactional systems as well as GUI applications (yes, Swing) in Java that have run extremely fast.
The top reasons I have found for Java being slow are
1. Lack of application of fundamentals of programming (such as taking care of the number of objects you create). Spring to some extent reduces this risk, if used correctly. The impact is the highest in Swing applications where layouts are nested too much just because someone didn't spend enough time to do the design properly. In some cases, even moving some unwanted "new"s out of loops will help things significantly.
2. Not using the right software and instead reinventing the wheel. I have used MQ Series for a distributed system that happily processed around 100,000 records or more per hour without any complaints. The average transaction was around 7ms. And it was all written in Java.
3. Not using threads optimally. One program that used the Java Advanced Imaging packaged processed and uploaded 50,000 images (each image around 200K) per hour easily when multiple threads were used (you have to of course check how many threads are optimal).
4. Not using a profiling tool to check your code. In the glory days of Borland, I used their OptimizeIt software - an excellent tool to detect object leaks, something that's ignored due to Java's garbage collection.
5. Finally, not tuning the JVM. After optimizing your code, you need to tune the GC so that it works for your application. Just leaving the defaults as they are (or just modifying the ms/mx values doesn't cut it). It's like expecting an auto-gear car to win in a drag race.
|
|
|
Message #308850
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").
There are two things you can always count on in our industry:
* The surprising extent of ignorance, and the immunity it shows to education; and
* A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++
|
|
|
Message #308852
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Don't whine about Java being slow
This has been an age-long (at least 10 years) complaint about Java and I have found in these 10 years that it's a load of bull****.
I have implemented a number of highly transactional systems as well as GUI applications (yes, Swing) in Java that have run extremely fast.
I agree fully that especially today, it is complete nonsense.
Most of the performance problems in Java programs are a result of bad design.
It's common for people to retrieve objects into a huge list and then process them one at a time. Not only is this slow, it requires huge amounts of memory.
Another thing is that it's common to see people doing things like this:
for (int b; (b = istream.read()) >= 0;) {
ostream.write((byte) b);
}
This is even considered "idiomatic Java" but it's (in my experience) up to 30 times slower than using a 1K array for the reads and writes. That means that you bring local file reads and writes down to networking speeds.
|
|
|
Message #308853
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
* A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
I'd say that's a more universal rule.
|
|
|
Message #308854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").
There are two things you can always count on in our industry:
* The surprising extent of ignorance, and the immunity it shows to education; and
* A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++
I'm going to take a stab at guessing that the commenter you're talking about is James Watson right? I mean, if you look at his first post (i.e. Confusing coded sentences.) and seeing how many posts followed (i.e. Most vocal commenter, having the most posts) for him to actually clear up what he was really trying to say in his first post.
Most everybody else made their point very clear in their first post on their views of the story, and Watson's tidbit on the guy who wrote his RPG XML Parser. :-). He seemed to have redeemed himself much later though. Just count how many posts he has made to get to a point that could have been made from post one.
Talk about redundancy in communicating. Maybe a LINT for redundant posts can help him out here. lol.
|
|
|
Message #308858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
James and I don't always agree, but he does tend to put a lot of thought into what he writes.
Thanks, buddy. I think usually agree with you though.
|
|
|
Message #308871
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
db4o performance a fault
Just had to comment on the cautionary example's use of db4o ;-) Absolutely hilarious ..... and I agree...just because something is wicked fast doesn't mean you use it to mix the cake batter. You can end up with egg on your face.
Cheers,
-Robert
db4o - The Database for Developers
..right tool for the job
|
|
|
Message #308912
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Yes. Java is too slow
Yes. Java is too slow. I'm not talking about runtime performance but in innovation in the language.
And how exactly is C++ doing any better there? Wasn't the x in C++0x supposed to be a 3 initially? Currently it probably even won't become a 9. Now the last language innovations where in 1998, that's at least a 12 year time span without any innovation. The std library had a minor update in 2003 orso. This was the kind of update that would seem small for a point update in Java (i.e. Java 6 u8 to u9).
|
|
|
Message #308920
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Has this actually happened...
...and if so, who was right? Java may not be slow now, but it *was* slow in the "late nineties". Talk about immature and instable database drivers, problems with the garbage collector. Even today, Java's memory model is less than perfect.
Recently, I saw code from a shop that used "best practices" to access a relational database. This included scrapping a proven, fast, but somewhat tiresome process of access data (using stored procedures in the database) with - yes - Hibernate3. One of the reason to do so was (of course and equally tiresome, "platform independence" and getting the SQL right). Development was more or less a breeze, but the performance of the thing was, well, not quite what was hoped for.
The reason was of course that the application did not bend the way Hibernate (or any ORM tool for that matter) would expect, since it consisted of a lot of data presented to the user that required various join operations on the database and updates that typically spanned multiple tables. You should have seen the stares when people looked at the actual SQL statements.
At the end, a lot of custom SQL had to be placed into Hibernate to get good performance and most of the advantages of ORM were lost. Moreover, Hibernate Mappings are in the deployed EAR Files. Also, to fix a bug or change some behavior in the database stored procedure was orders of maginitudes easier that to prepare a new EAR File and get it through Quality Assurance. Thus, the result for some people was "Java is not only slow but also inflexible".
|
|
|
Message #308949
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Has this actually happened...
Recently, I saw code from a shop that used "best practices" to access a relational database. This included scrapping a proven, fast, but somewhat tiresome process of access data (using stored procedures in the database) with - yes - Hibernate3.
As in almost all cases, the problem here is not with Hibernate3, rather with the designers/developers. Hibernate never claimed to be the 'fastest' database access mechanism. It's an ORM tool, facilitating access of RDBM as objects. That's why it has support for named SQL queries and stored procedures.
In one of my projects, we developed a matching routine (Lucene was at its infancy then) that connected to an AS/400 DB2 instance. We developed an ORM via Hibernate, which made the code quite flexible and easy to use, but we still kept certain core aspects of the routine in stored procedures. The result was a very fast search engine (around 100,000 queries an hour, almost 5 times faster than the AS/400 app we were replacing and enhancing). We also spent a lot of time logging the SQLs (using Spring's very nice AOP mechanism) and ensuring that all generated SQLs were tuned properly.
The result... the bottleneck move from the application to DB2. The system was as fast as the time DB2 took to execute the stored procedure.
Bottomline - don't blame the framework or the language. It's just a tool. It's up to the wielder of the tool to pick the right one for the occasion and apply it the right way.
|
|
|
Message #308951
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Has this actually happened...
As in almost all cases, the problem here is not with Hibernate3, rather with the designers/developers. Hibernate never claimed to be the 'fastest' database access mechanism. It's an ORM tool, facilitating access of RDBM as objects. That's why it has support for named SQL queries and stored procedures.
Of course the problem is not "with" Hibernate3. The problem is that a developer/designer has to choose from a limited toolset in order to create a maintainable solution.
Even today, I'd say the toolset is actually to broad, meaning that it is to complex to really take into account all the aspects of the tools used (In the original example JMS was mentioned. Interesting enough JMS is quite complex to handle, since various messaging systems support it in various ways, let alone failover behavior, subtleties in transaction support etc.).
That said, not only does "performance" matter. Development time is a critical factor in most projects as well. In the above example, Hibernate can be quicker to patch something together, but tuning it soon becomes as complex as tuning the original SQL in the first place.
|
|
|
Message #308955
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Has this actually happened...
Even today, I'd say the toolset is actually to broad, meaning that it is to complex to really take into account all the aspects of the tools used (In the original example JMS was mentioned. Interesting enough JMS is quite complex to handle, since various messaging systems support it in various ways, let alone failover behavior, subtleties in transaction support etc.).
True, but that's the con of having a democratic system than a monopolistic one, isn't it? Everyone thinks they can do it a little better than the other person. The onus is then on the developer to not be swayed by the 'latest' technology and even if so, pick it and use it only as appropriate. In your example, I fail to understand why they did not intersperse stored procedures or complex SQLs as applicable with Hibernate. Hibernate is great to map results into domain objects, but that doesn't mean you have to only use ORM.
In case of JMS, although it can be complex, we primarily used just it's point-to-point communication and didn't really touch the publish-subscribe part or any of the more complex persistent storage options, because we didn't need them - and that's my point. You understand what's there but then select only what you need from the lot as it applies to you.
In the above example, Hibernate can be quicker to patch something together, but tuning it soon becomes as complex as tuning the original SQL in the first place.
I don't agree. I've worked with a number of successful Hibernate implementations that scaled extremely well. Hibernate, like any ORM software, relies on a fully normalized database. If the database is not normalized (such as too many composite primary keys, etc.), then Hibernate, or any other ORM tool for that matter, will be a pain to use and implement - mainly because it specifically is not designed that way.
|
|
|
Message #308956
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").
There are two things you can always count on in our industry:
* The surprising extent of ignorance, and the immunity it shows to education; and
* A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++
Yeah. And he likes ASP.Net. [scratch head] Obviously he has not done anything complex with it.
|
|
|
Message #308957
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
If you read the article and then read the comments, you'll notice an interesting irony: that the most vocal commenter ("xtremezone" -- how cool is that? ;-) is basically the same person as the story is written about ("Dick").
There are two things you can always count on in our industry:
* The surprising extent of ignorance, and the immunity it shows to education; and
* A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++
Yeah. And he likes ASP.Net. [scratch head] Obviously he has not done anything complex with it.
|
|
|
Message #308962
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Has this actually happened...
I don't agree. I've worked with a number of successful Hibernate implementations that scaled extremely well. Hibernate, like any ORM software, relies on a fully normalized database. If the database is not normalized (such as too many composite primary keys, etc.), then Hibernate, or any other ORM tool for that matter, will be a pain to use and implement - mainly because it specifically is not designed that way.
Sure, I have seen successful projects with Hibernate and other ORMs as well. In particular when one can use the schema generation/updates and do a lot of prototyping wotk without ever leaving the Java layer. Nice.
However in a lot of cases, database structure is given and is often rather ORM unfriendly.
As soon as you do a lot of stored procedures / views etc., Hibernate scales of course - but so does plain JDBC and Hibernate gives you very little. It is in fact a lot easier and faster to implement a proper update statement compared to implementing a complex query.
Strangely enough, we have a development paradigm called DRY which is extremely popular among modern developers - the same frequently use Hibernate. When used on the server side, Hibernate repeats itself quite a lot, since the session can not be used for caching (as it can be in thick client). ORM also loads a lot more data than what the client actually needs, since it needs to contain proper objects for handling subsequent saves of data rows.
|
|
|
Message #308963
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
There are two things you can always count on in our industry:
* The surprising extent of ignorance, and the immunity it shows to education; and
* A strong correlation between the depth of ignorance and the vociferousness of the individual possessing it.
I cannot agree with this at all. On the contrary, there is no other "industry", where constant education is as rewarded as in our industry. Looking at the "industry" as a whole of course. A broad perspective is rather interesting and rewarding, since it allows you to judge what the latest product is all about - usually it is about renaming some well not concept or product and reselling it as the next silver bullet with a differnt name. This allows to sell textbook stuff like Pipes and Filters, Caching, Model-View-Controller, Object Oriented Databases as the next big thing. Mortage Certificates anyone?
|
|
|
Message #308968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
I cannot agree with this at all. On the contrary, there is no other "industry", where constant education is as rewarded as in our industry.
I can think of lots of industries. Genomics, off the top of my head where constant education is much more rewarded.
It could be an experience thing but I see people rewarded for phony education. Developers go to training courses about the next hot thing. 5 years later no one could care less about that same topic (e.g. CORBA.) I think what Cameron was referring to was real CS education. And if I am right in that assessment, I have to agree to a good extent. The software/IT industry is fad driven and chases after the mirage of tools that allow for commodity programmers.
|
|
|
Message #308970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
It could be an experience thing but I see people rewarded for phony education.
I agree. I don't see people being reward for trully educating themselves. In fact, the ones who are rewarded are those who can climb the ladder. Typically these are people who can talk the talk but seldom walk the walk. There are places and ways to be rewarded for educating yourself (ie what Cameron did). But these are few.
|
|
|
Message #308981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
I think what Cameron was referring to was real CS education. And if I am right in that assessment, I have to agree to a good extent. The software/IT industry is fad driven and chases after the mirage of tools that allow for commodity programmers.
Well, the Corba Training course may have been worthwhile if one had learned the general principles of remote communication. It can help a lot to judge the quality and applicabiliyt of todays "better" remoting technologies, like web services, EJBs, Spring Remoting etc.
I think "real" CS education is desirable, but education is also very much about understanding and learning a toolset.
If an engineer goes off to learn about a new piece of equipment or a new tool or a new software package for CAD or visualisation this is of course refered to as education - and rightly so. If a corporate developer goes off to learn about new language, application server or database features this is education as well.
|
|
|
Message #308982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Well, wasn't java 1.0 kind of slow?
1.0 and 1.1 was no match for compiled languages as I can remember. Nowadays I don't think there is any point in coding in C++ instead of java for performance. Many people still think Java is slow because it was slow in the early days. But things change and some people have too much earwax.
Heh, well many java apps are still slow and sluggish, but that is just framework bloat... Not the language being slow.
|
|
|
Message #308997
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
I cannot agree with this at all. On the contrary, there is no other "industry", where constant education is as rewarded as in our industry.
I can think of lots of industries. Genomics, off the top of my head where constant education is much more rewarded.
It could be an experience thing but I see people rewarded for phony education. Developers go to training courses about the next hot thing. 5 years later no one could care less about that same topic (e.g. CORBA.) I think what Cameron was referring to was real CS education. And if I am right in that assessment, I have to agree to a good extent. The software/IT industry is fad driven and chases after the mirage of tools that allow for commodity programmers.
Well, every industry has its fads and wrong turns. I don't think software development is necessarily unique in that respect.
I may change my mind someday, but today, I don't fear the commodity aspect. As anyone who's been in the business a while knows, the technology is one aspect. As James said, in 5 years, no one will care about today's technology. But you will always need to be able to to problem solve, to absorb the tech de jour, to play well with other teams, to be customer facing, to have vision, and to have passion if you are to truly stand out from the pack.
|
|
|
Message #308999
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
I may change my mind someday, but today, I don't fear the commodity aspect. As anyone who's been in the business a while knows, the technology is one aspect.
You are right not to fear the commodity developer idea. The reason is that it's not going to happen. Tools will get better and developers may become less technical but the core problem of translating requirements into working software is unchanged by this.
The problem with the concept of commodity developers, or as I term it: technical typing, is that the tools that chase this goal tend to limit what the developer can do. This is ostensibly to keep people with limited technical skills from getting in over their heads. In my experience, however, is that skilled developers will ultimately take control of these tools and the limitations serve only to reduce the quality of the work those developers produce. In a nutshell, these types of tools fail in every aspect.
Despite this reality being demonstrated time and time-again, IT management continues to buy the same snake-oil under different labels.
|
|
|
Message #309016
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
The problem with the concept of commodity developers, or as I term it: technical typing, is that the tools that chase this goal tend to limit what the developer can do. [..]
I think software developers should actively work to make their current roles obsolete. The more we do that, the more invaluable and irreplaceable we become ..
Our ability to obsolete our current roles is what enables us to move to the next level. Someone's going to go there; we can choose to move forward ourselves, or to allow atrophy to set in while we watch others surge ahead.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++
|
|
|
Message #309020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is Slow! - A Cautionary Tale
The problem with the concept of commodity developers, or as I term it: technical typing, is that the tools that chase this goal tend to limit what the developer can do. [..]
I think software developers should actively work to make their current roles obsolete. The more we do that, the more invaluable and irreplaceable we become ..
Our ability to obsolete our current roles is what enables us to move to the next level. Someone's going to go there; we can choose to move forward ourselves, or to allow atrophy to set in while we watch others surge ahead.
Peace,
Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++
I think this is orthogonal to my point. It's good to say "we can do better" or "this can be automated" and continually improve in terms of efficiency and quality. There are tools that do this.
But the tools I am talking about don't do that. They basically attempt to take one thing that a developer can do and make it possible for a less qualified developer to do it. There is no improvement in quality (usually quite the opposite) and eventually in every case I've seen, more qualified developers need to be brought in to fix the mess that results. Because these tools do not provide the necessary tools to provide quality results, these developers then put time and effort into working around the limitations of the tool in order to achieve mediocrity instead of providing good software. Where I work we use one such tool and we now have more staff than we ever before because it has a constant development curve for new tasks as it lacks any meaningful way of reusing logic. Each new task requires as much effort as the first. Any change in approach must be multiplied by the tasks that were done before (we are now in the task times 1000+ range). We basically have expensive resources executing repetitive tasks.
What I am NOT saying is that tools don't matter or that tools can make things better. What I am saying is there is a big difference between the goal of providing developers with more powerful, robust, and efficient tools and eliminating the need for skilled developers. The first one is a good idea. The second one is a pipe dream, as far as I am concerned.
|
|
|
Message #309097
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java is slow without any doubt
Out of my experience, Java IS slow. Sometimes it is VERY slow. You may get acceptable performance, but the number of traps to work around will be higher than with other languages.
I have seen C# performing better than C. Never seen that with Java. My best guess is that C# compiles everything to native while Java compiles what the VM considers necessary. As soon as the VM makes a mistake, Java fails.
Java is VERY memory hungry when compared to other languages. And it is STILL necessary to instruct the VM how exactly memory hungry it should be in order not to crash.
Those who say Java is not slow actually say that in many cases it is NOT UNACCEPTABLY slow.
Java has not perished yet for exactly one reason: it makes software development more predictable. Where 100 mediocre Java programmers have 80% probability to complete a project in 2 years and require 3 servers to run it, 5 good Ruby programmers have 30% probability to complete the same project in 6 months and run it on a low end PC. In a corporate environment that makes Java a clear winner.
|
|
|
Message #309146
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JMS (impl) too slow, xml too?
Your exemple of JMS is bad. We started using JMS... And it was infact far too slow.
We tried many implementations etc.
Then we went to simple TCP/IP (in java) and i was realy realy faster.
Iff plain old sockets-based passing works for you, then a message queue (like JMS impl) sounds like an overkill.
MQs are used for rather different purpose than simple messaging; just like relational DBs are used for tasks where simple storage as text files wouldn't work.
At the same time though JMS MQs can be tuned for very high message throughput, so it's not often that they are too slow for the task.
And as to object serialization; it really depends on tools used. For example, results from:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
indicate that xml-based serialization can be faster than regular Java serialization (and JSON even more so).
|
|
|
Message #309316
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Back to basics
Speed? What kind of application? A simple transaction to update a few database records or astronomical calculation or some maths calc like finding the value of PI using Gregory series and nn billion iterations? Obviously no one will use Java for astronmical calculations where many iterations are involved...Compiled languages are needed here...
Java vs C++ - Java is slow...But that alone doesn't decide anything. How about an interactive application (called online olden days) where user has to updat a few database records? The speed needs to redefined here in terms of the actual CPU (Java + DBMS), elapsed time, wait time (from user's perspective) etc. The sum total is the deciding factor.
But today's application frameworks make it confusing to measure all these in a meaningful way...I have often wondered 'who is stealing the CPU,,, how can my EJB wait for times like 1000+ seconds clocktime??' ? Java code, Weblogic code or the DBMS region!! Add a few more packages, and you have a complete mess.
|
|
|
Message #328945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java slow than C++
Anybody that has ever used a non-trivial Java program or has programmed in Java knows that Java is slower than native programs written in C++. This is a fact of life, something that we accept when we use Java.
However, many folks would like to convince us that this is just a temporary condition. Java is not slow by design, they say. Instead, it is slow because today's JIT implementations are relatively young and don't do all the optimizations they could.
This is incorrect. No matter how good the JITs get, Java will always be slower than C++.
|
|
|
Message #328946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java slow than C++
Anybody that has ever used a non-trivial Java program or has programmed in Java knows that Java is slower than native programs written in C++. This is a fact of life, something that we accept when we use Java.
However, many folks would like to convince us that this is just a temporary condition. Java is not slow by design, they say. Instead, it is slow because today's JIT implementations are relatively young and don't do all the optimizations they could.
This is incorrect. No matter how good the JITs get, Java will always be slower than C++.
Regards,
Victoria
Poker Bonus Codes
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
