Howdy, Some folks on the list may remember a thread, from a little more than a year ago (http://mail.python.org/pipermail/pythonmac-sig/2004-April.txt.gz), where I asked the following question:
"I'm trying to track down a bug that shows up when I run BitTorrent for Mac OS 9, and I'm not sure whether it's a problem with BitTorrent, MacPython, or some combination of both...in BitTorrent, when you resume downloading after having stopped (say, to restart your computer), the client checks the portion of the file you've already downloaded. (I assume it does this to test for corruption and so forth.) Normally, under Windows or OS X, this takes just a few minutes. "But for some reason, under OS 9, it takes an absurd amount of time -- something like 1 hour per 100 MB. From what I understand, "checking [the] existing file" is _not_ a computationally-intensive process, and shouldn't take anything like the length of time it takes on Mac OS 9 (using the btdownloadheadless.py client, which is the only one that works under OS 9). As it stands now, if I'm interrupted near the end of an 800MB download, I have to let my computer run overnight just to get back on!" At the time, several list members were kind enough to offer suggestions, through which we established a few things: -- Quitting all other open programs -- including the Finder -- doesn't help. -- Increasing the memory allocated to MacPython doesn't help. -- The problem doesn't seem to have anything to do with virtual memory. Alas, between the lack of data and my own lack of Python skills, we didn't get much further. For want of a solution, I borrowed a Windows computer and did my BitTorrent-ing on that machine. And so the matter has rested for the past year. However, I've just resumed using my OS 9 machine to participate in torrents, and recently, I discovered an important data point that may shed light on the problem. If I may elaborate: While btdownloadheadless.py is "checking existing file", the MacPython window normally updates every eight seconds or so, changing the "percent done" to reflects how much is left to check. On a file of, say, 250MB, that "percent done" changes by an average of 0.1% every update -- which means that checking the whole file takes about 8000 seconds, or 2+ hours. However, if you resize the MacPython window by clicking the lower-right hand corner, it updates *immediately*. And if you resize the window constantly, clicking on the lower-right corner over and over again, it updates nearly as fast as you click it [1] -- at the minimum, you can get it to update once per second, which means that it's checking the file about eight times as fast as it would otherwise be (at the expense of your having to sit there, clicking hundreds of times!). It's still not as fast as on Windows, where it takes mere seconds -- but cutting the amount of time it takes from 150 minutes, to 20 or fewer, would still be huge. So, does this information make anyone go "Aha!", by any chance? It seems to me that it's now unambiguously clear that the problem is not a processor bottleneck, but something else entirely. I'm no programmer, but I'm guessing that something about resizing the window (you don't actually need to resize it, but only to "attempt" to, if that makes sense) is either (a) encouraging the OS to give a higher priority to MacPython, or (b) jump-starting MacPython into performing an operation that it's otherwise, for unknown reasons, deferring. If anyone has any thoughts on this, I'd love to hear them, and will be grateful for your willingness to grapple with an obscure bug on an outdated OS. It's not an earth-shakingly important problem, but it'd be awesome if there's a solution! Thanks, Phil [1] Footnote: the optimum rate seems to be to click the window, and resize it, immediately after it scrolls and updates -- slightly faster than once per second -- and in a steady rhythm. Doing it faster doesn't do any good. _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
