|
|
|
|
Back to newsletter 037 contents
It?s time for another edition of the Round-up, the best talk of the major performance discussion groups. It is when I dive into these groups that I realize the dedication and time it takes to build and maintain a vibrant community. For a while, I was concerned that we might lose Java Gaming as it being assimilated into the www.java.net family of sites. But, the gaming community proved to be more than strong enough to survive. And, their strength shows in the number of discussions and technical depth of the postings in each group. Similar kudos should be given to the Java Ranch and the ServerSide. These sites have been the staple of this column. I?ve tried to incorporate other sources but each time that I do, I find that there is a complete lack of depth or presence. It is these two characteristics that can keep performance tuning discussions interesting and fresh. And with that, we start into this month?s roundup.
For our first look at the Java Ranch, we will summarize a series of responses to a question of when to use PL/SQL and when to stick to Java. As is the case with most applications, there are bits that can be implemented more effectively using alternative technologies. With J2EE applications, there is always the alternative of implementing bits of the application in PL/SQL. The question is, should we always choose the more effective technology? Though the answer would seem to be a resounding yes, lets look at the issues. One of the primary reasons that we code in Java is that the semantics of the language support our preferred programming paradigm, object oriented programming (OOP). We use OOP for a number of reasons. One reason is that OOP has proven to be more effective in handling complexity than any of the previously prescribed paradigms. Thus, implementing business logic in PL/SQL would not be considered a best practice in a Java application. As one response indicated, as application logic has become more complex and JDBC drivers have gotten better, quite often, the DB is no longer the bottleneck. However, it is worth considering implementing bits of the application using PL/SQL for performance optimization, if the DB is identified as being a bottleneck.
In another posting, we find a description of a system that would appear to be in a "semi-deployed" state. The application was to be fully deployed before the first of December. The description of the problem and was succinctly and calmly put forth. The question portion of the posting displayed a completely different tone, one of panic. Both Jack and myself run into this type of situation all the time. In fact, panic is the number one reason that we developed our architectural review engagement/product (but you can read about that elsewhere). In these cases, there is typically (but not always) not much that can be done except start working on a plan to improve performance. A ranch hand did offer some good tips but you need a solid plan to know when and where to apply them. A plan also acts to serve notice to the users that you are working towards making their life better.
In our first posting on the serverside, we find a question of how to measure network time in a distributed application. This is treated as a performance question and some excellent advice is offered in this regards. Unfortunately, the wrong question appears to have been answered. The original posting was about how to measure network time so that one could keep the system clocks in the distributed system in sync. Not a trivial problem to solve and as is the case with all important and non-trivial questions, there are people working on an answer. For the latest information, I?d recommend a trip to http://www.ntp.org, the keepers of the Network Time Protocol.
Every once in a while, you run across a benchmark that produces some interesting results. Consider the posting that compared the performance of the JDO, EJB/CMP and JDBC. What is interesting is that the results (in this case) showed that the JDO provided the fastest result followed by the JDBC and then CMP EJBs. What I find interesting is that there are no test results provided, there is no indication as to the test conditions, nor is there any indication of what the test looked like. In addition, it should be noted that the JDO uses the JDBC to do its work. Which makes me wonder what the raw JDBC code looked like. As always, your results may vary depending upon usage.
If you?ve not been to the Java Gaming site in a while, I suggest that you take a look. Without a doubt, these guys have a showcase of what can be achieved with Swing.
It is without a doubt that whenever a thread drifts at Java Gaming, it?s always for the better. Take the case of a discussion centered on the speed of ArrayList in the JDK 1.4.2. By all reports, it has undergone a significant improvement in performance. Which is nice to hear because up until now, this group had been pretty much limited to using Vector. So, this is great information but then, the thread drifts and it gets better. It appears as though the new auto-boxing feature will rely on a compiler trick. In case you?re not aware of what auto-boxing is, I would direct you to my blog at http://kirk.blog-city.com. Even if a compiler trick is used to help optimize the situation, there will still need to be objects created and released and that equates to more garbage. Fortunately, the advances in garbage collection seem to keep pace with the advances in garbage creation so it may not be as bad as it sounds.
In yet another discussion, what started out as a complaint about the size of the JRE turned into a series of threads that brought forth a number of interesting points. First, a number of the gamers are using Jet, a Java native compiler. This product takes Java code and compiles it into an exe. As well all know, running an exe offers many advantages in that it requires far less modification of end users environment. Jet is produced by Excelsior and can be found at http://www.excelsior-usa.com/home.html. In addition to the configuration advantages, Jet will reduce the overall size to be downloaded by the end users.
I?ve run into a situation that I feel that I?d like to share with you all. In the performance discussions at the serverside, there is often a vendor presence. In most cases, postings by vendors (or people working for them) are in response to some question that has been posted or to clarify some point that has been made. And, that?s ok, for vendors often provide the best answers to people?s questions. Again, in a majority of these cases, it?s more an employee of the vendor that is responding to the question and that person is motivated by the overall sense of wanting to participate in communities like those fostered by the ServerSide. To these people, I tip my hat. There are, however, a few that use the community for blatant commercialism. It?s not that I?m against commercialism; I?m as commercial as the next person. It?s just that a technical discussion group is for just that, technical discussions. Now, when a vendor does violate this edict, they are usually admonished and it?s typical to see an apology appear. In the case that I?m citing, the vendor not only tried to initiate a discussion based on clear commercialism, the person who posted the message tried to conceal her identity. Now, if that were the only ?socially questionable? offense committed, then you wouldn?t be reading about it here. But, this vendor has committed other acts that in my humble opinion have been cause for pause. For all of their efforts, Candle Corporation now has the distinction of earning the coveted Meadow Muffin award.
Back to newsletter 037 contents
