How to improve Java app efficiencies?

Most Java apps are quicker with 1.6. Should also apply to TWS. FutureScalper's suggestion about DirectX would definately be worth a look.

As to whether you will get any faster charts is an open question. If the performance issue is not related to Java performance, then you may not see much improvement. best just to try it out.

FYI, the principle developer of JFreeChart which is the charting library used by TWS, reported significant performance benefits with Java 1.6.
 
Sounds like good Java hints. But,
I use Quotetracker with about 10 charts up, Propht.net for stocks (which I'm not trading just now) and IB for futures data feed.

In Booktrader, if I pick a reasonable price point with a reasonable population of bids/asks, I get a "fill" (blacked quantity) in less than 1 second.

I lack FutureScalper's sophisticated timing information. I was merely asking what the delay between the actual time (on my tray clock) and the displayed time on TWS trade window might mean.

Perhaps the target bid/asks 15 seconds behind the market? Can mean the world in futures or forex.

I will Snagit an example later today and post.
 
I re-read my original post, and thought I had better clarify my statement "45 second round trip cycle time".

What I meant by that was, if Globex:ER2U7 was 792.3 (last) with a bid population at 789.7 and up and asks at 792.5, that the "last" would take out all the bids (or asks), move through the profitable sale area, and return back where it started in, say, 45 seconds. If there is indeed a data lag of 15 seconds, that's like shooting at the tail end of a flock of geese flying by, and not really knowing what direction they are going!

But the "trade" lag appears to be almost nil. What gives?
 
A front-end should be specific to the type of trading work you do, whereas TWS itself is rather "generic". Check IB freelance tools listings for candidates, or their forums. Seems there's been an explosion of specialist add-ons for TWS, as TWS itself has become slightly more "bloated". BTW, many of us would like a "TWS Lite" small kernel for API usage only, but so far no committed development along those lines. Are you familiar with the TWSAPI Yahoo group? Those guys are specialists in specialist front-ends to TWS. A useful resource. FS.
 
[Geez, let's try this again. I wrote out a wonderful explanation and tried to give you the .REG import file and the forum rejected my post. Note to self: always save post before transmitting it]

Win32PrioritySeparation is a crfitical system variable in Windows XP systems controlling OS processor scheduling.

Here's the Microsoft article describing the bitmask fields:

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/29623.mspx?mfr=true

You need to think carefully about your binary, hex, etc in order to understand this, but it makes a big difference in a hot interprocess communication environment on Windows XP, such as front-ends connected to TWS and running Java processes, etc.

The attached file should have a .REG extension, but I have set it to a .TXT extension for upload purposes. After you download it, you must change it to a .REG instead of a .TXT in order to important the registry contents (if you want them).

Anyway, to make a long story short, I prefer to tune my system to have "fixed quanta", "short quanta" and "equal foreground and background priorities".

The attached file's contents are these:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl]
"Win32PrioritySeparation"=dword:00000028

This is a registry export file and you can use it to import data automatically. Remember, rename .TXT to have the .REG extension before using it. After importing it into the registry, you reboot your system.

Have fun ! FS
 

Attachments

CORRECTION TO My POST REPRODUCED BELOW

-XX:ThreadStackSize=128 should be increased to
-XX:ThreadStackSize=192

Apologies if anybody crashed on startup using the smaller stack size. Maybe they put something "recursive" in a version of TWS, ha ha :( FS

Here's how I run TWS, using both Java 6 and the "server vm".

Since the "server vm" is not distributed with the client JRE from Sun, its installation is "special". You are unlikely to need anything more than the standard "client vm".

IF you wanted to use the server vm (which you CANNOT do without special installation, then
"-client" would be replaced by "-server" when the server vm is used, but this file could be used by anyone with the standard client vm to run TWS, rather than the shortcut which is supplied in the installation:

My advice: use the standard "client vm" and don't think you're missing anything.

This .bat file is located in c:\jts\runtws.bat on my system.

The TWS shortcut is changed to "c:\jts\runtws.bat"

The contents are:

c:\WINDOWS\system32\java.exe -client -Xbatch -Xss128k -Xms174m -Xmx174m -Xnoclassgc -XX:+ForceTimeHighResolution -XX:CompileThreshold=50 -XX:CICompilerCount=2 -XX:ThreadStackSize=128 -XX:+AggressiveOpts -cp jts.jar;pluginsupport.jar;jcommon-1.0.0.jar;jfreechart-1.0.0.jar;jhall.jar;other.jar;rss.jar jclient/LoginFrame c:\jts

ALL ON A SINGLE COMMAND LINE; EMAIL FOR A .BAT FILE IF YOU WANT.

Standalone TWS is assumed, and Java JRE 6 or higher is assumed.

On each TWS upgrade, simply replace their shortcut by the one shown above.

Items to note:

1) ms and mx 174m parameters fix the min and max java "heap" size to 174 megabytes. These can be tweaked but should be set at a fixed size.

2) CompileThreshold forces the HotSpot compiler to compile more java code into machine code when only 50 interations are met. This take a bit longer to "warm up" and uses more memory, but is overall faster.

I"m something of a performance freak so I run both TWS and my Java platform under the Java Server VM. This is not appropriate, nor necessary for the ordinary user. I am often running 5 Java processes flat out, so I need the scalability. You almost certainly do not need the server vm.

Another thing: On Windows XP, using the Java 6 runtime, the DirectX system is used by default. You may note that TWS shortcut sets disables DirectX, because they do not know whether you have a Java 6 VM. This is the first VM on which DirectX works normally.

A parameter in the TWS shortcut may say:
-Dsun.java2d.noddraw=true
THIS MEANS DO NOT USE DIRECT DRAW (DIRECTX)
IF, AND ONLY IF, YOU HAVE A JAVA 6 VM, you may set this to false, or simply remove it altogether, so your screen updates may use DirectX for higher performance.

So although you may be running Java 6 which, at this writing is not technically supported by TWS development; nevertheless it works fine. It will be using DirectX for more efficient screen updates, unless it is inhibited by noddraw=true. In that case, set noddraw=false TO ALLOW DIRECTX

Garbage collection: It is more efficient if it is NOT incremental, but garbage IS collected only when heap is becoming full. Also, the compiler is more efficient compiling Java code to Machine code when it does it as a "batch" operation, rather than concurrently.

Anyway, anybody wants to know a bit more there's lots of info on the net, and advanced usage of the server vm is something I might explain by email.

FS. [/QUOTE]
 
Quote from FutureScalper:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl]
"Win32PrioritySeparation"=dword:00000028

Have fun ! FS
More...
No need for all of that...just click on Background Services in the Advanced Tab of the Performance Options section of My Computer, Properties.
 
You must log in or register to reply here.
Back
Top