|
|
|
|
Back to newsletter 035 contents
The problems of stateful singletons and multi-threaded applications was raised. The succinct answer was: Either avoid using singletons; or use a pool of objects; or use synchronization to allow access by only one thread at a time; or use ThreadLocals.
Should I compile my Java application to native code for better speed? The answers ranged from: try it and see; to "the code is already compiled to native code by the JIT; and "it won't make a bad algorithm run fast". The consensus was that a distributed application (which this was) would probably not see any difference in performance (neither worse nor better), and in any case, why try to anticipate problems. Finish the application and profile it to find the bottlenecks then fix those.
What do you do when the optimized version of your bean is faster - but only sometimes? This question produced an interesting answer: don't give up. Keep testing, monitoring the network traffic, DB usage and CPU utilization to get a better idea of what is producing the performance variation. If you can find the problem fix it. If cannot find out why the new bean is not always faster, it may be better not to use it, thus avoiding introducing new bugs
Is Java fast enough for making games? This is hardly a new question, especially for the JavaGaming forum, and such discussions are always educational here. The particular game in mind here was a multiplayer 3D robot game. The discussion participants were quite clear that Java would be a very good match for this game. Java3D already gave them a big head start on the basic 3D requirements, including collision support; openGL is supported with GL4Java and LWJGL (faster more lower level).
Gamers generally want complete control over the animation, and usually want to bypass Swing so that they know exactly what is happening. The question of using Swing in games was raised. Does it have overhead, are there synchronization issues? An interesting quote was pulled out from Michael Martak's full screen exclusive mode API trail, where he says "Feel free to call Swing methods such as paintComponents, paintComponent, paintBorder, and paintChildren directly from your rendering loop". Of course you still need to worry about asynchrnous updates, so either you put all the calls to paint in your own thread or in the Swing thread. Otherwise you have a difficult multi-threading problem on your hands. Generally, it looks like gamers tend to avoid using Swing at all, which is reasonable - most games have their own very particular style for buttons and other widgets, and do not need to go through the standard event handler. Standard widgets are to make your application have a standard look and feel, games don't really need that.
One discusson about enhanced decoupling of classes focused on the cost of reflection incurred in initialization. The expert opinion was that the performance overhead of reflection is insignificant, compared to the benefits that reflection brings--loose coupling, with the ability to switch implementations of any interface in configuration files, without modifying Java code. In addition, it was pointed out that in 1.3 and more so in 1.4, reflection has a very low overhead.
Another discussion asked about optimizing EJBs so that they didn't call ejbStore and ejbLoad methods every time the EJB was accessed. Basically, these methods are called each time because the database holds the "master" copy of the EJBs. So to ensure that any changes are reflected in all copies of any particular EJB, each access must go to the database (in case the "master" data has changed since the EJB was last accessed); each update must go to the database to ensure that all other EJB copies remain up to date. Of course this is vastly inefficient for most applications, especially if there is no clustering involved. Respondants to this discussion pointed out that there were multiple locking strategies to optimize this situation, and the manual ($10 for the JBoss developers guide in this case) would be an excellent investment. Most application servers include support for avoiding ejbLoad() calls if you're sure no-one else is accessing the database. Optimistic locking is similarly helpful to optimize the situation. Finally, one respondant pointed out that there are also caching products such as Tangosol, Gemstone, and Isocra, which can be usefully employed to eliminate unnecessary database communications.
Back to newsletter 035 contents
