Why are you even using IB charts when Quotetracker charts are free and do an excellent job off IB data and has a hell of a lot more features.
2 good reasons: first i got a mac and is not compatible with qt, second ib charts are reliable and dont lag.
The comment was directed to the original poster. I have been using QT for awhile and have not noticed any lag unless you are talking about milliseconds which does not concern me.
IB should make hardware accelerated charting. Would be a lot less sluggish, they should also start displaying the data as it downloads, retrieving the most recent data first.
I use QT's free version, but it will only show a maximum of 2 days on the charts. To quickly get more days on an Intraday chart, looks like I am forced to subscribe to QuoteTracker. IB's charts just don't cut it, status quo. They DO lag, and often a chart will just sit there and not even load. There is something SERIOUSLY wrong with IB's charts that needs to be fixed. I've tried them on 2 different computers with over a gig of memory and over 3.2 MHz processor, one pc running 55 windows processes and the other one running only 19 windows processes, and there is little to no difference. Also, IB charts don't display pre-market trading data like QT does. As an aside, I only use Windows (XP Pro) because of QuoteTracker. I really prefer using TWS in linux, and, of course, QT doesn't do linux, so for linux users, QT is not an option. At least TWS does linux and MAC, so I give IB one up on QT on that. I understand that it is not necessarily the data feed, but the backfill process that may be the problem with IB's charts.
Ironically, the reason the charts are slow is the same as to why they run on all platforms: Java! TWS does not directly interact with your computer at all. It interacts with Java and Java executes in the OS. So Java determines how efficiently things are done. It's one of the burdens of multiplatform development. Ursa..
Mostly wrong. Java programs execute in a Java Virtual Machine (JVM). JVM is a program that executes in the same way any other program executes, calling on OS services as required and subject to the same privilidge restrictions as any other program. To say the JVM executes in the OS is highly misleading - it executes in user space not kernel space. It really is about time that the myth of slow Java was put to bed. Yes it is slower than C/C++, but not ten times slower. Probably not even two times slower. Modern JVMs use Just In Time compilation (JIT) to translate Java byte code into native code on the fly. After years of development these techniques have become very sophisticated and very efficient. In some cases Java code can exceed the performance of natively compiled code because optimization can be done at run time. Natively compiled code is optimized at compile time only. IB will probably put down the poor performance to the free charting library that is being used which is not really designed for real time charts. In my estimation this is largely correct, but there are things that could possibly be done to speed things up which I am not going to go into here.
Absolutely correct. I was not aware the word 'in' could be read as 'kernel' app. I meant 'directly using the OS'. It was intended to put down Java, certainly not. I'm sure it is very well possible to build Java apps that are just as quick as C ones. But I never saw one in the wild, yet. I think this is not caused by Java itself, but by the intentions of the mainstream developers when they choose for using Java. They want to build a multi-platform app and do not care to optimize for performance on every platform, even if it were possible. I think it is harder to optimize Java for things like graphical representation on a specific platform so it becomes a matter of priorities. If it is in your opinion possible to write optimal/optimizable code for all 3 platforms at the same time than I stand corrected, but again, it seems hard to do because I never saw one. Ursa..
Hard to imagine the 'slowness' of the backfill has anything to do with Java at all. Has anyone done a test using the api, to see how fast the data actually gets delivered after a request? I've noticed the futures backfilling seems faster , but I have no hard proof at this time.