: : I'm guessing the COM+ infrastrucrure is adding another layer of code execution. I would think especially if the component was commiting and rolling back transactions.
: That's the interesting thing. There's about the same number of layers.
: Python way:
: 1. VB program creates valid XMLRPC structure.
: 2. VB program instantiates XHTTP object from MSXML
: 3. VB program calls socket server written in Python on same machine
: 4. Python program unpacks XMLRPC request
: 5. Python program calls stored procedure using Oracle module
: 6. Python program packs result into XMLRPC response
: 7. Python program sends response back to XHTTP client and closes socket
: COM+ way:
: 1. VB program instantiates ActiveX DLL class
: 2. VB program calls method on new object
: 3. Object uses ADO recordset to pack information into an XML structure
: 4. Object instantiates ActiveX DLL class registered with COM+
: 5. Object passes XML structure to COM+ class
: 6. COM+ class unpacks ADO XML information
: 7. COM+ class calls stored procedure using ADO and OLEDB provider
: 8. COM+ class passes stored procedure return value (string) back to first object
: You would think that using ActiveX DLLs would be much faster than XMLRPC and a python script. In fact, if the VB program instantiates ADO objects itself rather than using our database proxy class(es), it runs in about half the time as the python way. So the problem isn't ADO per se, but most likely in the class(es) we have running under COM+. COM+ is used specifically for scalability and robustness. Which becomes all the more amazing when running multiple instances of my VB client causes the COM+ class' performance to drop off by orders of magnitude.
: Today I am going to get a log of the network traffic between my machine and the Oracle database. This should allow me to eliminate the database access as a factor in the differences. My python server is using a SessionPool and COM+ is supposed to be pooling connections, so connection time shouldn't be a factor.
: $ select * from users where clue > 0
: no rows returned
COM+ is another layer on top of the base COM API ... right?
VB is a COM pig, because it has to implement extra interfaces behind the scenes to be compatible. Some Active-x controls, ive heard, implement between 7 and 15 interfaces.
Also think about VB object creation ...
A. All objects implement IUnknown
B. Query IUnknown for such and such ...
C. Maintain reference count behind the scenes ...
COM+ expands COM ... COM+ hijacks your vb component and adds more invisible code execution ... since COM+ requires components to be stateless, your component is creating and destroyin objects with every call i think ...
Also, ive had problems w/ COM+ and it's one of those frameworks you have to use absolutely correct, or you will suffer.
Now weigh that with the fact that Python isn't COM and doesn't have as much leg work to get an object reference. If you think about it, it calls upon behind-the-scenes C or C++ like VB but without the COM.
These are all theories that i'm clawing at, so tell me what u think.
Also, if u didn't do this already, and i'm sure u did ... compile the vb dll with all the compiler oprimizations like ... "Turning off bounds checking" etc...
I hear you can sometimes increase the speed of the vb code two-fold.
Also try the bench-mark without COM+.