|
|
|
|
Back to newsletter 028 contents
I happened to catch the European Figure Skating Championships Dance competition. As should be expected, the German dance couple proved to have the most interesting costumes. They were dressed up as a pair of very strange looking robots. The graphics on the front of the costume appear to have been lifted from perfmon (Microsoft's system performance monitoring tool) proving that performance-monitoring tools are not just for geeks anymore. And now for this months roundup.
At the Java Ranch, an innocent question regarding Jikes yielded a few nuggets of wisdom. First, it's been long known that JIKES is much faster at compiling source than javac. One does have to be aware that JIKES can produce different byte code from the same source, which under some circumstances can cause a VerifyError exception to be thrown. As for the nuggets: always compile your code using the compiler that was bundled with the JVM you're planning on using before deploying to production.
Does using static methods offer a performance advantage? If you're using one of the new versions of the JDK, then the compiler will take advantage of the information to in-line the method call. In the posted test, the saving was measured at ~50% ( 420-241) over 100000000 calls. This amounts to 179 ms over 100 million calls or 1.79 nano-seconds per call. But, one should consider the effects of using statics. Objects, by their nature, provide you with isolated pockets of state and behavior. Excessive use of statics breaks this model and will most likely result in a much poorer implementation. In my humble opinion, the design cost associated with this performance strategy far outweighs the benefit.
To StringBuffer or to +. That was the question that was put to the test during a micro-performance benchmarking exercise. The test was simple concatenation of a string in a loop. That the initial test did not yield the expected results, did yield a number of plausible explanations. The time to concatenate String using the + operator was not much different than those where StringBuffer was used. Of course, we all know that the compiler will replace the + operator with the append() method found in the StringBuffer class. One other point: be careful when you under-take a micro-benchmarking exercise as results can easily be misleading.
From the server side, we start with a posting that's asking about the use of EJB 2.0 to bulk load a database. Now, there might be good reasons to use an EJB server to bulk-load a database but most databases come with their own optimized bulk loader. It is doubtful that anything will have better performance characteristics.
It would seem that JCache is finally coming into it's own with a number of vendors offering product. A number of these came out in a thread on the question. Included in the list are Chutney Technologies, Versant, Tangosol and as well as product from one of our sponsors, GemStone.
Here is a question that is often asked but never answered. How much computing capacity do I need to support my application? Why is this seemingly simple question so hard to answer? Consider this. To produce a good estimate, one will need to evaluate a complex set of requirements without having any data on which to base an answer. It's difficult to provide an answer in a vacuum. So, how can one fill the information void? Well, in many instances, the new system is being built to replace an older system. Even if the new system is offering many new features, one can still obtain some information by looking at the hardware being used by the older system. The difference in functionality (between the new and old system) maybe used to calculate the extra capacity needed to support the new features.
From the gaming community, we have a number of questions from a newbie. The most notable asked if using an obfuscator would help performance. Obfuscators do two things to a class file. First, they shrink it by truncating all of the entries in the name space. Secondly, they will do some static byte code optimization. Though the performance impact of each individual change on the class file is unknown, it is commonly seen that obfuscating your classes does result in a performance boost.
In this day and age, you'd think that no one would question using threads in an application. But here there is a long (and sometimes heated) debate on the usefulness of threads in a gaming environment. Yes, there are a group of game developers that were arguing against the use of threads! The interesting part is that you can't dismiss their arguments. First, we can agree that the primary purpose of threading is to maximize the utilization of your hardware resources. For example, if your process is reading data from a source, it typically has to wait for that data to arrive. During that time, the CPU will most likely be idle. Introducing another thread into the mix may allow one to further utilize the CPU. The question is, does the cost of managing threads outweigh the benefits of being able to further utilize a resource (the CPU in this case). You might raise the point that threading allows a process to utilize multiple CPUs in an SMP environment. The argument here is that the target audience is using single CPU and consequently have fewer opportunities to recover the cost of threading. In addition to this, gaming (as well as other computationally intensive activities) already does a good job of fully utilizing the CPU which could very well result in one not being able to recover the cost of multi-threading. So, although the benefits of multi-threading seem intuitive, it appears that there are still instances where highly threading an application may not be the approach.
Finally, there is an extremely long thread questioning why SWING would appear to be so slow. As with most threads of this length, it expanded to include a number of interesting sub-topics, why SWING doesn't take advantage of graphic accelerator cards, color bleeding and blurring, and performance issues with the 2D and 3D graphics packages. What the thread fails to do is identify the exact case of the performance bottleneck in swing. But, there are plenty of clues. For instance, SWING takes very little of the CPU. Even though SWING creates a lot of garbage, the collection of that garbage does not seem to present a problem. The machine being used had enough memory that the OS was not swapping pages. The animation was not doing any input so that was ruled out. It was finally speculated that SWING batches repaint calls that get fired on a periodic basis. If this is true, then one has to wonder why SWING is attempting a server optimization on a client. My hypothesis is that there might be a class that is either ignoring or missing a signal that causes SWING to stutter. What was most interesting was watching how each hypothesis was evaluated on it's merits and then tested. The results drew a conclusion that in every case proved the hypothesis to be false.
It would seem that blogs are all the rage. Don't feel left out if you don't know what a blog is, the rage is still young. Think of a blog as an online diary that you get to share with the world. How is this different than having web pages? Well, one of your peers can add comments to you blog. How is this different than the Wiki? The differentiation here is a bit thinner but wiki is a more publicly owned forum than a blog. If you're interested, my blog is at kirk.blog-city.com. www.blog-city.com is hosted by N-ARY, a consulting firm in Scotland operated by the venerable Alan Williamson.
Kirk Pepperdine.
Kirk blogs at kirk.blog-city.com
Back to newsletter 028 contents
