I thought that might be the answer. Thank you On Feb 17, 2017 4:53 PM, "Tim Roberts" <t...@probo.com> wrote:
> Stephen Chapman wrote: > > > > Since it was a simple example I was only passing a single int for a > > parameter and returning 0. As far as I know COM servers don't cache > > responses I have never seen that happen anyway. > > That's not what I said. There are two parts to a late-dispatch COM > call: finding the address of the routine to call, and calling the > routine. Finding the address is a relatively expensive operation, > because you don't just have a pile of function pointers. You have to go > enumerate the list of methods and properties until you find the one you > want by comparing the names as strings, then go ask what the function's > signature is, then fake up a function call with that signature. It's > possible that C# caches that information so it can just make the call. > > However, I was assuming that both the client and server were in C#. Now > I see that it's only the server that's in C#, so my comment does not apply. > > > > However the question was really why in the order of magnitude is > > python so much slower for the same exact call. I have slightly > > changed my example to bump the number by one to show that it is not > > caching. And pass I am passing 4 parameters now so as to show how > > much longer python takes as you add more arguments. So here are the > > results. I have just done a simple timer in this example. > > ... > > So the function now bumps by one and has 4 parameters passing... So > > as you can see the Python code took 11 times longer to do this simple > > process > > If i add 5 more paramters C# only slightly goes up and Python more > > than doubles. > > Really, that's just the way it is. Interpreted Python code is always > going to be slower than the just-in-time compiled machine code from C#. > COM interfaces are optimized for C++, so the Python interface is always > going to have something of an impedance mismatch. 20 microseconds per > call is pretty fantastic, in my view, but if your application is one > where performance over millions of calls is absolutely critical, then > you should not move to Python. > > -- > Tim Roberts, t...@probo.com > Providenza & Boekelheide, Inc. > > _______________________________________________ > python-win32 mailing list > python-win32@python.org > https://mail.python.org/mailman/listinfo/python-win32 >
_______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
