[python-win32] Python win32Com Server DLL

[Denis Akhiyarov]

.NET uses RCW to cache calls into COM. I once used pythonnet to call into
COM from Python using .NET COM interop. But this is not ready for general
use due to the amount of boilerplate code necessary to make the calls. See
this issue for more details.

https://github.com/pythonnet/pythonnet/issues/260

On Sun, Feb 19, 2017, 6:04 AM Stephen Chapman <schapman1974 at gmail.com>
wrote:

> I thought that might be the answer.  Thank you
>
> On Feb 17, 2017 4:53 PM, "Tim Roberts" <timr at 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, timr at probo.com
> Providenza & Boekelheide, Inc.
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20170219/9b0d4703/attachment-0001.html>