[python-win32] speed of win32com versus comtypes

[Mark Hammond]

On 11/02/2011 9:33 AM, Brad Buran wrote:
> Hi Mark:
>
> I finally had a chance to sit down and test your suggestion.  It
> worked beautifully.  The speed is now on-par with that of comtypes.
> Since I'm not really sure what _get_good_object_ does, anything I
> should need to watch out for since I've bypassed _get_good_object_?

If the function ever returned a COM object instead of a "simple" type, 
you would get back a "low-level" COM object that doesn't quite work as 
you expect (but even then, it would be trivial to manually "wrap" it 
like _get_good_object_ does.

Cheers,

Mark.

>
> Brad
>
> On Wed, Jan 26, 2011 at 9:21 PM, Mark Hammond<skippy.hammond at gmail.com>  wrote:
>> On 26/01/2011 3:38 PM, Brad Buran wrote:
>>>
>>> I've been using win32com.client for the past year or so.  Recently, I
>>> noticed that there was a bottleneck in my code, and I tracked this
>>> down to _get_good_single_object (line 478).  When using comtypes
>>> instead of win32com.client, calling the ReadTagVEX method on my COM
>>> object is 4.8 times faster so the slowdown appears to be in
>>> _get_good_object_.  The COM function in question, ReadTagVEX, is
>>> supposed to return an Array of VARIANT.  These arrays are quite large
>>> (on the order of 100,000 or 200,000 samples) on each read.
>>>
>>> I'd much rather stick with win32com.client if possible.  Are there any
>>> suggestions for speeding up this function?  I already know that the
>>> array returned will be an array of float32.
>>
>> You could just call InvokeTypes directly using a copy-paste of the generated
>> makepy code - somewhat ugly, but probably effective.
>>
>> (There is probably an optimization opportunity to avoid the call to
>> _get_good_object completely when the result of the function is other than a
>> generic "object" (ie, VT_DISPATCH) or array of such objects - but in this
>> case, the function declares it does return a generic VT_DISPATCH, so the
>> optimization wouldn't be able to be used in this particular case...)
>>
>> Mark
>>