Does TWS load quicker if it is given more memory?
Are you running a 32-bit Java JRE? TWS should be able to pull almost all of the 32 GB available on your system, if needed, with a 64-bit Java JRE.
TWS uses its own bundle Java that comes with it...it doesn't use any other java installation. And you're wrong...talk to IB..they'll Tell you TWS has a memory allocation limit.
It's not Java. I make charts in Java and they are all just as smooth as something programmed in C++. It's likely just not very well optimized. TWS should run fine on Apple. I honestly don't really have much of an issue with TWS aside from the slow start-up time. Probably takes about 30 seconds to 1 minute to fully load.
You consider 30 seconds slow. ?
The only limit mentioned in their own guide is based on the Java JRE OS Type:
https://ibkr.info/article/2170
"Because of this OS architecture limitation, if you have a 32-bit OS, the maximum memory allocation for the TWS must not exceed 2048 Mb." That article mentions no other memory limit outside the OS limit.
TWS offers a 32-bit and 64-bit version of TWS. Since the .jar file / Java application is OS type agnostic, the only difference between the two packages must be in the JRE. I suspect that it is possible to run TWS using another JRE anyhow, but haven't actually tried...never found a reason to do so.
A quote from IB support message directly
"Unfortunately, with the number of windows and tools you have open at the same time, you will see a poor performance level. Java won't utilize more than 2 gigabytes of ram, so you won't really benefit much from having a computer with a lot of ram."
TWS is a piece of garbage that they'd rather spend time adding stupid features that nobody wants versus fixing basic performance issues and glitches. Support guy basically told me to kick rocks because TWS cant do what any other platform I've used can do.
"The issue is not the number of data lines you are requesting but the number of TWS windows you have open a the same time. The number of Windows you have are pulling too much resources that the Java Virtual Machine cannot handle effectively."