Thanks especially to Futurescalper. Two questions: 1) If I have this included it doesn't run: -XX:CICompilerCount=2 If I remove it it runs fine. 2) If I wanted to run one of the current web versions (867) how do I force it to load with this command instead (if its possible)?
Well, I assume you have Java 6, and compiler count can be 1 or whatever the default is. This relates to the HotSpot compiler allocating multiple compile threads to dynamically compile java bytecode to machine code. Comprehensive tuning is always an interative process. Web versions? Well, I believe those are applets. You would be able to influence the JVM by using the Java Control panel and painstakingly putting in the run time parameters which you wanted the applet to use. Probably too advanced, but you're welcome to try it. I always use the standalone version for high performance; the browser-based would not be my preference at all, because I use a high performance front-end connected to it and don't want the environment to be controlled by Internet Destroyer (or whatever)... FS
Thanks FS. I will wait for 876 to come through on download. I'm currently using 872.6 because all versions from here to 876 incorrectly label the time in history refresh packets (late by the bar length).
I apologize for not leaving a pointer to documentation on these bizarre java "hotspot" vm options. Here it is, from Sun's site. http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp Elsewhere I posted about tuning Windows XP Win32PrioritySeparation, possibly running without a pagefile, in which case you want both adequate physical ram, and memory conservation by disabling prefetcher, and a number of optimizations which can be found in "tweak" articles across the internet. Don't get "tweak-itis" ! But there are certain key tweaks you should apply to your main trading platform. For filesystem speed, if there's lots of i/o, use the Windows command: fsutil behavior set disablelastaccess 1 This avoids writing a "last touched" timestamp every time the file is read. There are so many things about comprehensive system tuning, but I can only tell you that a properly tuned java system can be screamingly fast. All this talk about "realtime" with Windows is a joke. You can't get, and you don't need, "realtime" anyway, although "fast and responsive" is very important and achievable. FS
Baloney. I've tested it and it makes a HUGE difference....especially when you have Background priority set. Programs like PriorityMaster make all of this tweaking possible, because it manages to prevent other apps from being "locked-out".
I've tested Thinkorswim's excellent Java trading platform as well as IB's TWS. Both tested well with Priority Master. Strange thing: Java 1.6 has not yet been endorsed by EITHER TOS or IB because of bugs and side-effects in the 1.6 JDK. This would indicate a short postion in JAVA, formerly SUNW. (Note: remember Ed Zander, was a former Sun exec)
Though I have never had a problem with Java 6 and TWS.... Cust svc sometimes blames it and has me try Java 5, but no problem I've encountered in TWS has ever been traced to Java 6. Also, based on input from another ET'er and some research, I now run TWS with the following optimized Java parameters: -Dsun.java2d.noddraw=false -Xss128k -Xms256m -Xmx256m -XX:+ForceTimeHighResolution -XX:CompileThreshold=50 -XX:+UseFastAccessorMethods -XX:+AggressiveOpts I didn't test each one rigorously but the combo does seem to run better.
EXTREME PERFORMANCE Ran across some extreme performance flags for the "server vm" in case you want to go to the trouble of installing it. Basically the "client vm" is delivered with the jre. To get the server vm more comprehensive optimizations, you have to install the jdk, and then get the jvm.dll under the "server" folder, and make a server folder under your jre installation parallel to the client folder which already exists. Then you can say "java -server..." How much of this works with the client vm, I do not know. For extreme performance you really need the "server vm", as I stated above. Check these little-known options which over-ride the Hotspot compilers heuristics and enable it to consider and inline much larger Java methods down to machine code: (taken from a snippet of jnlp) j2se version="1.6.0+" java-vm-args=" -server -dsa -XX:+ForceTimeHighResolution -XX:ThreadStackSize=192 -XX:CompileThreshold=5 -XX:+AggressiveOpts -XX:CICompilerCount=1 -XX:+UseBiasedLocking -XX:+RelaxAccessControlCheck -XX:MaxInlineSize=8192 -XX:-DontCompileHugeMethods -XX:+UseFastAccessorMethods -Xbatch -Xss192k -Xms240m -Xmx240m -Xnoclassgc ... MaxInlineSize can increase the size of a method the compiler will "inline", and by disabling the DontCompileHugeMethods, you enable it to compile much larger methods (ignored by default) into machine code as well as possibly inlining them for execution. I've tried this, on my custom trading platform which uses a lot of Swing and crazy processing, and it SCREAMS. You may have to adjust some stack sizes, etc., but apparently, this stuff is magic for HIGH performance when you really NEED it. FutureScalper