Your question is too general. Swing is the only part of Java that is likely to pose any performance issue for most trading apps. To get the best out of Swing a developer really does need to know their stuff. For example here is an article on optimizing performance of "christmas tree" applications such as TWS quote pages: http://java.sun.com/products/jfc/tsc/articles/ChristmasTree/ As you can see they do get very worthwile speedup. I am certain that some performance issues are the fault of the developers or rather their management for not ensuring they have the right technical training. As somebody else posted here, if the heap is too small it is a performance killer as the runtime repeatedly runs the mark/sweep/compact garbage collection algorithm in an attempt to free up some heap space. Aside from checking that, I don't know if there is a lot else a user can do to speed things up. You could try other JVMs such as IBM or BEA Rockit, but I doubt if there will be a lot of difference. The same goes for JVM options - I doubt if fiddling is going to make a lot of difference. There seems liitle doubt that Java 1.6 has significant performance improvements over 1.5 and should be used unless there is some special reason not to. I have developed my own real time charting application in Java (using JFreeChart library with some enhancements to get good real time performance). It is running on Kubuntu Linux 64 bit with six 19" screens, Java 1.6 64 bit on a Core 2 Duo. With twenty or thirty charts, some with very short bars (eg 5 TWS "ticks") and lots of plots on each chart there are no peformance issues. Under normal market conditions CPU utilization rarely exceeds 5% and in fast markets 20%. Every "tick" is rendered - as it should be. I can run broadcast digital HDTV on one screen and it's still more than fast enough. As part of this I also a have real time scanner that can scan for any compound boolean expessions of time series. That could be expressed better but you get the idea - things like CLOSE > SMA AND RSI < 30 OR ....... Even scanning hundreds of stocks using a real tick feed (not tws), and evaluating the expressions on every tick, CPU utilization is laughably small.When I first started testing this I was shocked by the speed. So I don't really buy the "Java is too slow" bit at all. No doubt C++ is faster, but Java is fast enough. I also know that had I attempted this project in C++, it would have taken twice as long and I'd probably still be dusting off gdb looking at core dumps. I have a long backgound in C and to a lesser degree C++ programming on Unix systems. Wild horses wouldn't drag me back to using C++ for this sort of thing. This post is also a plug for Linux, which is very capable of supporting high performance charting. Six screen snapshot with HDTV:
Depending on your hardware (>1 CPU) and your level of technical expertise, you can significantly improve the performance by tuning or replacing the default garbage collector. http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
I also do not buy into the 'Java is not fast enough' camp. I posted this early last year. I would also not return to C++/MFC. If you still have any doubts pick up a copy of 'Killer Game Programming in Java' as it covers most of the java and performance debate issues very completely. The book also has a several complete source code examples of game programs that are very fast rendering. Details on how to use faster graphic hardware apis are included in the book, but so far I have not found them to be necessary.
The idea of moving to java 1.6 is an interesting one. For J-Trader (version 6), we could not run it at all after upgrading to Java 1.6 last month. Was then forced to remove Java 1.6 and 1.5 to get J-Trader running again. Do not know what caused the problem. I just tried uninstalling all versions of Java on the testing computer today. And then adding just Java 1.6 this time. Somehow it works perfectly this time. Will let you all know if the overall performance has improved.
On this forum about 2 months ago, there was a big discussion over running realtime trading apps in general, especially under Windows. I run a Java trading app under Windows 2000 and it really screams. One of the secrets is to optimize the priorities of all running applications and processes. This is not easy to do under Windows....because there was no thought to giving control to the user to control priority when launching an app. So this programmer set-out to provide this functionality under Windows: http://www.prioritymaster.com/ Please don't ding him for the hoaky website look, but his program is the "real deal" and allows you complete control over all processes and applications. In my set-up, I tell Prioritymaster to run Javaw.exe at "realtime" priority....the highest. Also, I "demote" a lot of the other "housekeeping" processes to a lower-than-normal priority. This really provides the necessary control to insure the trading app is getting the most of the CPU. I am using Windows 2000 only because it is a much leaner O/S than Win/XP IMHO.
One comment (opinion only) about running W2K as opposed to XP, soon Vista, etc. bec it's leaner. "True." BUT the tradeoff is, security is tighter on newer OSes -- esp. Vista -- and security patches from MSFT come out faster for newer OSes. As a matter of fact, I believe 2K is in maint mode. Given that security is important for these apps, I would say buy a new faster, preferably quad core, PC. The tradeoff to me is clear. On a Q6600 or faster, I don't think anyone will experience any performance problems w/java apps under Win XP or Vista. I'm not yet ready to say go Vista over XP as there're still many glitches. I've been using Vista for 2 months and many of the glitches are surmountable but require research into the appropriate updated drivers, etc. (My PC can still not properly sleep though I never use sleep so it doesn't bother me much except ideologically.) Security on Vista is might tighter with protected mode for IE (limits which files can be accessed), user account control requiring confirmation for all administrator activities including writes to key system directories, etc. Hopefully SP1 in the fall can be a clear winner over XP.
I promised to report the results I got from using Java 1.6 with JTrader 6. Comparing to Java 1.4 or 1.5, the overall CPU load is indeed reduced (10% or so) and the responsiveness of JTrader gets better.