My results: Delphi: 1500 quotes/sec VS6 C++ 2000 quotes/sec VS6 VB 9000 quotes/sec If someone has an explanation, please do post it, lol.
I've also tested with nothing but a counter in the event. 500-700 qps seems to be all it can handle. (The CPU that is) That is using C#.Net. This is the 1 and only reason I'm not using their quotes. Worthless.
Well, the thing is, that all other event handling is probably also way faster in VB (tradeupdates etc), so at the moment it sounds like VB is THE language of choice for the Sterling API (although that's not really fair to say, since it will really depend on the number of events to handle per second vs the rest of the code)
One thing to do is to use a profiler: http://www.red-gate.com/Products/ants_profiler/index.htm I would compare VB.NET and C++.NET or C#.NET. Then you can also look at the CIL generated for both and see if there is something obvious that makes one faster than another, and may give you a clue as to why you are seeing what you are seeing. Otherwise, it is there are way to many variables and it would all be guessing. nitro
I'm not using .NET, since it will use interop to translate COM messages which will result in a huge performance drop. If you have other idea's how to reverse engineer the COM stuff, please let me know (I'm good with ASM, but just don't know how to RE the COM events, since i don't know where to set breakpoints)
I ran some new tests, this time I timed setting a property of STIOrder: STIOrder.TIF. When looping this 5000 times, I found on my setup: Delphi takes 22 seconds VB takes 14 seconds C++ takes 10 seconds I've reverse engineered the generated C++ code, I found that about all it does is call the windows "NdrClientCall2" API. From the MSDN: http://msdn.microsoft.com/en-us/library/aa374215(VS.85).aspx Which makes sense of course, it's transmitting the TIF property into the base.exe process this way. Going to reverse engineer the Delphi stuff tomorrow and try to find out what the heck it's doing I wonder if it's using the same windows API ...
Did some initial reverse engineering of my Delphi code. I found that it's using the same windows API (NdrClientCall2), but it calls it twice ! Apart from that, there's a lot overhead. Anyway, not sure yet why it's calling that API twice. Below is the important part of the Delphi disassembly: The calls to NdrClientCall2 are in the 2 routines printed in bold. Anyway, as for now, it's obvious that Delphi just plain sucks at COM, and VB isn't doing that bad at all. Setting object properties is about 30-40% faster in C++, which makes sense. However, I'm still very confused why VB is beating the crap out of C++ when it comes to the COM event handling, going to try to find that out next, althought that most probably won't be very easy ...
very interesting. I was poking around with my code today and I found something interesting that's undocumented but I have no idea what it does. STIQuote.Destroy and STIEvents.Destroy Anyone know or have a guess of what they do? - mnx