If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

File download is slow on MAC

VERIFIED FIXED in M14

Status

()

Core
Networking
P1
critical
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Tom Everingham, Assigned: Scott Collins)

Tracking

({perf})

Trunk
PowerPC
Mac System 8.6
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], URL)

(Reporter)

Description

18 years ago
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
(Reporter)

Comment 1

18 years ago
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.

Comment 2

18 years ago
Putting on M14 radar, and adding perf keyword.
Keywords: perf
Target Milestone: M14

Comment 3

18 years ago
putting on beta1 radar, per beta criteria priority #2 - performance
Keywords: beta1

Comment 4

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 5

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

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] [02/18/00]

Comment 6

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

Comment 7

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

Comment 8

18 years ago
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.

Comment 9

18 years ago
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?

Comment 10

18 years ago
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.  

Comment 11

18 years ago
Changing summary from: "ftp download slow on Mac" 
Summary: ftp download slow on Mac → File download is slow on MAC

Comment 12

18 years ago
I think someone on dp's team (someone with a mac) should take this.
Assignee: valeski → dp

Comment 13

18 years ago
Scott said he would take this one.
Assignee: dp → scc

Comment 14

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 15

18 years ago
Scott can you update progress on this.
(Assignee)

Comment 16

18 years ago
Obviously, if it's PDT+, it must also be a P1
Priority: P3 → P1
(Assignee)

Comment 17

18 years ago
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.
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] [02/18/00] → [PDT+] [expected fix date unknown]

Comment 18

18 years ago
Need a more current ETA please?  Any new data?
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] [expected fix date unknown] → [PDT+] [investigating]
(Assignee)

Comment 19

18 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] [investigating] → [PDT+]
(Reporter)

Comment 20

18 years ago
I cannot check this right now because of bug 29360
(Reporter)

Comment 21

18 years ago
measuring around 14 seconds to download 6 megs.  Much better.
verified:
Mac OS8.6 2000022908
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.