On Tue, Jul 8, 2008 at 7:29 AM, Mark Hammond <[EMAIL PROTECTED]> 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. _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
