[python-win32] speed of win32com versus comtypes

[Brad Buran]

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_?

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
>