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.hamm...@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 > _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
