IB TWS: slow!, overloaded?

Quote from Kirkx:

... Remember that it's Java based and Java is a memory and resource hog. ...
More...

But there's memory unused and CPU isn't maxed (when I'm not maxing one of four cores with circling the mouse).

And, with Java code that is being called over and over, it doesn't get "interpreted" each time. It's loaded, "compiled" and it's the "compiled" result that is repeatedly called. Performance hit should be under 10%, and it's low-cost these days to throw money at hardware to exceed any 10% hit. I've got my own Java trading GUI written and now face multi-threading order management through the API. I haven't put metrics into my GUI to measure lag as visually I can't detect any.

I'm puzzled as to why so slow without resources maxed. TWS memory settings a good place to start.
At first glance, it appears that all charts are run by a single thread, instead of each chart or chart window having their own thread.

Tomorrow I'll see how it runs under load with the new memory settings...
 
Quote from Canoe007:



I've got physical memory sitting unused. Any reason why I shouldn't up the max mem from 1024 to 1536?

More...

Another performance enhancer is to run TWS and your charting application from a RAM disk. I use the one from a company called SuperSpeed http://www.superspeed.com/desktop/ramdisk.php. It works on XP, Vista and they have a 64-bit version for Windows 7 also. With some minor enhancements TWS should be running great for you. I haven't read through all the responses but also check and make sure don't have anti-virus or firewall issues as well. This could be a major bottle neck to performance also.
 
Found some notes from a Java white paper on 2d graphic optimization.

Runtime Flags For Win32

* -Dsun.java2d.noddraw=true
Setting this flag to true turns off DirectDraw usage, which sometimes helps to get rid of a lot of rendering problems on Win32.
* -Dsun.java2d.ddoffscreen=false
Setting this flag to false turns off DirectDraw offscreen surfaces acceleration by forcing all createVolatileImage calls to become createImage calls, and disables hidden acceleration performed on surfaces created with createImage .
* -Dsun.java2d.ddscale=true
Setting this flag to true enables hardware-accelerated scaling. Hardware scaling is disabled by default to avoid rendering artifacts in existing applications. These rendering artifacts are caused by possible inconsistencies between the scale method that the software scaling operation uses (nearest neighbor) and the different scale methods that video cards use. Certain events that occur while an application is running might cause a scaled image to be rendered partially with hardware scaling operations and partially with software scaling operations, resulting in an inconsistent appearance. For now, you can enable acceleration by setting the ddscale flag to true .
 
The noddraw was already part of the command line in the desktop shortcut. There isn't space to add the other two.

So, since XX command line parameters are not recommended, I dropped -XX:MaxPermSize=256M to try the three Java recommends for Win32.

Full load of open charts and windows as first detailed.

The system was already more responsive with increasing the stack to -Xmx1024.



With the three recommended Parameters & -Xmx1024:

Three cores are averaging around 5% with occasional spikes to 10%. One core is running around 20% with spikes to 80%. Tri-chart chart windows have lag between the charts of the same security, between 1/2 and one second. Draging an order on the chart has some lag but the chart continues drawing without any visible delay. Circling a mouse drives the one core to 80%-90%.
 
To make room to test another recommended parameter
-Dsun.java2d.opengl=false
I had to drop one of the others. I dropped ddoffscreen.

No visible change in core usage from the latest test. Mouse circling to 90%. Tri-chart chart windows have the candle charts lagging the line chart by 1/4 to 2 seconds. Last, Bid & Ask update with 1/4 second of each other. Dragging an order spikes one core to 95%, but there is very little lag. Refreshing a chart results in a gap in the indicator lines for the time it took to refresh the graph. Expanding menus to show infrequent items takes four seconds (display is set to simple mode).


These two tests do not give ideal results, but they're a lot better than before upping the stack to -Xmx1024M.
 
My remedy before:
1. Get registry repair software, e.g. Registry Mechanic -- Most effective;
2. Try old version of JRE;
3. Try old version of TWS.
 
Quote from Bob111:

or simply moving the mouse across the chart and your CPU usage will spike up to 100%

i did report this issue several times. FEW YEARS AGO..
More...

Not for me. quad core, win 7 x64, cpu <10% , mostly <5%, moving over a chart not a factor. And Im running a TON of other apps.


Problems like this seem to be system specific. This is why they can't fix it, since it aint the code (for the most part)

Ill sell you mine for 10k, cure all your problems.
 
Went back to the stock settings to check under a similar load.

Core usage is slightly higher on one of the low usage cores, the other two are the same as the other tests.
The high usage core is somewhat higher, but not significantly, but it spikes higher when you use features.
Menu expansion takes seven seconds.
Dragging an order on the chart spikes to 90% and there is huge - and scary - lag: you have to watch where the mouse pointer is and not where the order line is. Would not feel safe trading with this behavior.
Mouse circling spikes to 95%, but falls back to 80%.
Refresh has the gap in indicators.
Last, Bid & Ask updates between charts within 1/4 second.
Candle charts lag line charts by 1/4 second to five seconds, but typical two to three seconds.
Click buttons to create orders spikes the high usage core to 80%. Minor lag for order to appear in the order table, but takes another second before it appears on the chart, appearing in turn on other charts within a half second. Good enough.
Dragging a chart around also has huge lag, but that's not something you do often or in the heat of trading.

So it overwhelmingly appears that -Xmx1024M is essential for my uses.
 
You must log in or register to reply here.
Back
Top