[python-win32] killing overlay extensions

[TK Soh]

On Tue, Jul 8, 2008 at 7:29 AM, Mark Hammond <mhammond at skippinet.com.au> wrote:
>
>> The debugging trace suggests that IsMemberOf  are called after
>> GetOverlayInfo, which itself is called when Explorer starts up.
>
> That is correct - GetOverlayInfo is called just once per process IIUC.
> Having this function fail should prevent your IsMemberOf being called - but
> once it has been successfully called, you are in the same position you are
> now.
>
>> In any case, as I said in my reply to Mark, Explorer slows down
>> noticeably just by having the extensions turned on, i.e, calling the
>> IsMemberOf function. Probably due to the overhead within pythonwin COM
>> mechanism.
>
> That would surprise me, as the overhead should not be much at all - a lock
> acquisition, creation of a tuple for the args, getattr for the function and
> a few calls.  No IDispatch is involved here, so there isn't much magic at
> all.  For most folders, you can expect one call per file - which typically
> will only be in the dozens of files.
>
> So if the overhead of doing nothing is too great, I can't see how the
> extension could do much work at all.  In other words, I'd be quite surprised
> if the overhead of a Python implementation that does nothing is more than
> the (say) C++ TSVN overhead when it is actually talking to subversion,
> stating files on disk, parsing the 'entries' file, etc.  TSVN uses locks
> quite liberally too, etc....
>
> Maybe we need to measure this overhead somehow? There are probably some
> optimizations we can make in some cases too - eg, caching the function
> objects rather than looking them up each call, etc, but as implied above,
> I'd be very surprised to see that make a measurable difference unless the
> number of calls is truly huge and the real work being done by the function
> is close to zero.

I think I should revise my claim.

Following Tim's advice, I just tried it again, and somehow the
slowdown seemed much less obvious now. I am quite certain this used to
be a problem at some point of time in the past.

However, one thing has changed in the last few days though, that I'm
now using build 211 you just released. Though I am not sure if it
would have any impact on the topic we are discussing. FYI, earlier I
was using the build 210.5 you created specially, and build 210 before
that.

If necessary, I can try again with the older builds to confirm the
slowdown, but I wonder if it's really worth the effort, especially
given the much limited time I get to spend on this. I am guessing we'd
be okay as long as I using the 211 or the newer builds.

In any case, we are definitely going move towards shell extension in
C++, as we need to do this to address other issues that are not
immediately solvable with current python/pywin32 implementation.

I will keep the list posted if anything comes up in the future. Thank
you all for the comment and feedback.