Overview Description: ftp download's are very slow on the Mac. Steps to Reproduce: 1.) Go to an ftp site 2.) select a large file and download Actual Results: File downloads ok but very slowly Expected Results: should download much quicker Build Date & Platform Bug Found: MAC OS8.6 2000012601 Additional Builds and Platforms Tested On: NT and Linux work fine

I thought I'd add that it took almost 5 minutes to download a 9 Meg file. On NT, similar size files took 10 - 15 seconds.

Putting on M14 radar, and adding perf keyword.

putting on beta1 radar, per beta criteria priority #2 - performance

Putting on PDT+ radar for beta1.

Try it now that the buffering is in place for file writes.

I have no clue on this one. waiting for testing to see if it's even a problem anymore.

tever, is this an http problem too? file download in general on the mac?

I just tested the 2/10/00 build 4.7 gets about 380-450 k/s M14 gets around 25-32 k/s so I would say that there is still a significant performance gap.

definately! Thanks for testing david. One more thing :). I'm 99% sure this is not an FTP problem, can you try downloading an HTTP file (www.boulderdesign.com/Bin.zip) and report back your findings?

I got just about the same numbers where 4.7 was a bit slower at 350k/s and mozilla was stuck at 32k/s so I think you assumption that the bottleneck is outside of ftp is probably right.

Changing summary from: "ftp download slow on Mac"

I think someone on dp's team (someone with a mac) should take this.

Scott said he would take this one.

Does Scott have time to look at this right away? Other than writing some nsLocalFileMac stuff I don't have any other m14 stuff to look at if the tree is ever green enough to check in.

Scott can you update progress on this.

Obviously, if it's PDT+, it must also be a P1

With advice from Simon, I'm using the Mac Instrumentation SDK. So far nothing is standing out. It's leaning towards looking like thread starvation. David, if you want and/or have time to help with this, I could use any help you can provide. Jim Roskind suggests an alternative is innappropriately sized buffers. Gagan favors the thread starvation theory. I just need to get something in the profiling to prove or disprove any of these theories.

Need a more current ETA please? Any new data?

The actual bug is that socket transport is choked on Macintosh by its current lack of pollable events. This bug affects every byte that comes over the network, as far as I know, except for DNS lookups. The real fix that will bring performance to 4.x levels (or perhaps _better_) is to implement pollable events on Mac. In the meanwhile, changing the current poll timeout value from the initial guess of 250 msec to 5 msecs yields a substantial speed increase across the board. The performance is typically 8-10x better. This is most visible in file downloads using ftp (or any other protocol, for that matter), but also makes downloading ordinary web pages snappier. UI responsiveness has not been compromised. This fix does not bring performance to 4.x levels, but we are withing a factor of 2 or 3 now instead of 20. I am now going to mark this bug as fixed. Further work on implementing pollable events should be under a new bug, probably assigned to <gordon@netscape.com>. We believe this problem is also the root cause of his PDT+ bug #2611, which I would love to mark fixed as well. File download is now significantly faster, and will be faster still after pollable events are implemented for Mac.

I cannot check this right now because of bug 29360

measuring around 14 seconds to download 6 megs. Much better. verified: Mac OS8.6 2000022908