Also, about the .NET, I wanted to add that you have to keep in mind here that we're using a COM object/API; .NET uses a wrapper for them called 'interop', which basically is a layer that translates all messages between the COM component and the managed layer; therefore .NET will always be slower here already, so that will probably be a major source of delay ... Can't wait for monday, to time my Delphi app for the quote messages, maybe it even isn't as slow as I thought it was Although i would be really surpised to get as much as 5000 messages/sec, the whole damn sterling API seems so damn slow ...
If you set Code: stiEvents.SetOrderEventsAsStructs(true); You will get called back as a standard method with a struct parameter, instead of as an event. It is a slight optimization, maybe. To the rest of the posters. While Sterling is at best average, lack of documentation is often the case when you are a programmer. Unfortunately, you have to figure things out on your own. What I do is I instantiate everything, then output to a log file some message when a method is called and can see a "call stack" postmortem. This way I reverse engineer the documentation. This is what I often do when the documentation and example programs are lacking. nitro
Can anyone explain what GetQueueCount is and what I would use it for? I assume it's a look at how my many quotes are backed up, but what would I do with this info besides knowing for sure that I'm getting quote lag?
Can someone please tell me WHY THIS IS SO ? I mean with all of the licensing revenue Sterling pulls down from all of those prop shops, why is the API SLOW and POORLY DOCUMENTED ? Why can't they spend a few bucks on improvements here ? It also sounds as if the tech support is marginal as well.
I'm using VB6 and a Core2Quad oc'ed to 3.4GHz... I can average over 6000 quote updates / second... I tried porting my app to VB.net 2008 at one point and couldn't even get quotes to work properly... I never figured it out and ended up sticking with VB6... - mnx
I can only get 1200 quotes/sec on an intel dual core e6850 @ 3 ghz with my Delphi code So what's the deal here ? I'm sure it has to do with the COM interprocess communication, since Delphi is normally always way faster than VB code ... Anybody any ideas/suggestions ?
Bingo. I tested a COM interface with the IB API and it really, really sucked-up CPU and it was slow as heck. If you can get the callbacks to work properly, a DLL interface will always be faster.
Yep, that seems to be what it is. I used to watch that for quotes -- once it would process more than 500 qps, it would quickly build... 1000... 5000... 10000... 50000.... restart app, quotes too backed up. You can get that from other interfaces as well. I.e. the STIEvents. I don't update graphics (positons) until the event queue is 0 so I don't update a table repeatedly and bog the CPU even more.
Today I wanted to see how far I could push the ATS in VB6. Currently registered 1200 symbols and have yet to get over 2/10ths of a second of lag. QPS are in the mid thousands sometimes, but most of the time sits between 500-2000. I'll add another 1000 or so tomorrow. I was stuck doing only 150 before because of my old computer and it didn't cross my mind to add more symbols after I upgraded. I tried the getqueuecount for the first time today too (don't know how I missed it before). Having it update every second. Majority of the time it's 0, but I've seen it up the hundreds a few times. Now, how do we use the DLL interface directly? Is there a tool where we can view its classes and what not? I'm just an amateur programmer. I sure would like to move away from VB6!