Closed Bug 2611 Opened 26 years ago Closed 24 years ago

loading complex (cnn.com) pages much slower on Mac

Categories

(Core :: Networking, defect, P5)

Product:
Core
Component:
Networking
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: gordon)

References

(
URL
)

Details

(Keywords: perf, platform-parity, top100, Whiteboard: [nsbeta2-][PDT-] no estimate -- may be fixed)

Load a complex page (e.g. www.cnn.com) in the viewer on both Mac and Windows. Note how much faster the basic structure of the page appears on Windows; and how much sooner the images appear. It takes approx twice as long on Mac to finish loading this page, on roughly equivalent machines. It would seem that this performance difference lies in the networking code, or perhaps in timing interactions between netlib and layout. My guess is that work could be done in NSPR's Open Transport code to optimize our OT calls, an area which has received very little attention since MacSock went away.
OS: All
This may be a combination of 2132 and 2231.
See also 2151, to which this bug is most closely related.
URL: www.cnn.com
I loaded www.cnn.com on Win95/Jan25 build and Mac 8.5/Jan22 build (A G3) at the same time and they loaded equally as fast. sfraser, what Mac do you have?
Okay. So, I spoke with Simon, and played around a bit. I'll try the CNN site, but here are results of two complicated sites. To increase the probability of the results being relevant, I (of course) cleared the cache prior to testing, and am using IE as the control. (This is probably a statistically meaningless comparison, given the negligible sample size, lack of repeated samples for each web site, lack of consideration for time to resolve domain name at end of URL, etc.) Windows: IE 4 Viewer (1.25.99 build) (Disney) 9 seconds 4 seconds (2.25X) (USA Today) 6 seconds 3.5 seconds (1.7X) Mac OS: IE 4 Viewer (1.25.99 build) (Disney) 20 seconds 14 seconds (1.4X) (USA Today) 30-40 seconds 16 seconds (1.8-2.5X) In other words, Viewer appears to be approximately about twice as fast as IE 4 cross-platform with something like 30% variance between Mac and Windows (but that variance could be easily attributed to other factors, as noted above.) So, I can't see evidence of a problem, but I also don't think the above provides evidence that there isn't a problem. --- Eli (who would be murdered by Professor Banks if he saw such a simplistic and broken attempt at a statistical experiment by a former student. ;)
Inserting Milestone info.
Setting all current Open/Normal to M4.
Whiteboard: [Perf]
Putting on [Perf] radar.
Status: NEW → ASSIGNED
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Priority: P2 → P5
Target Milestone: M4 → M7
Steve, have you tried to reassign this to someone who has some remote connection with page loading time? There is no way you should have this bug. setting priority to P5, milestone to M7
This is another bug awaiting landing of the NSPR OT fixes (mainly async DNS lookup). I didn't want to dump it on gordon to close since he's already got enough OT bugz. That and I wanted to keep at least one performance bug open to remind us to test Mac performance vs. other platforms.
Target Milestone: M7 → M8
Target Milestone: M8 → M9
Blocks: 8691
Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)
Target Milestone: M9 → M10
Target Milestone: M10 → M11
Blocks: 12671
mass-moving most m11 bugs to m12
paulmac..is this still an issue?
I'll defer to simon, steve, et al on this, I'm not the one to say that whether this is 'fixed' or not.
Depends on: 18738
This is probably due in part to 18738 (slow image loading).
Mass-moving non-PDT+ bugs to M13
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
Keywords: perf
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.
Target Milestone: M13 → M14
moving to m14
Keywords: pp
can we get the latest data on the cnn site? steve, can you profile to figure out where the slowdown is coming from? putting on the beta1 radar.
Keywords: beta1
Summary: [PP] loading complex pages much slower on Mac → [PP]top100 loading complex (cnn.com) pages much slower on Mac
PDT going to wait for data before making a beta1 call
adding top100 keyword.
Keywords: top100
Adding [NEED INFO] to Status Summary.
Whiteboard: [Perf] → [NEED INFO]
Summary: [PP]top100 loading complex (cnn.com) pages much slower on Mac → loading complex (cnn.com) pages much slower on Mac
Blocks: 25824
Let's make sure this is on waterson's perf list. PeterT: What's the disposition of this bug?
PDT has asked SDagley for more information on this bug before making their +/- decision. He is out sick today, but it is one of his top priorities as soon as he returns. My quick/dirty tests on a low-end Mac (PB 3400, 128 MB RAM) show 5.x taking at least twice as long to load several common pages (including CNN) as 4.7 on the same machine. I don't think there is any question about our failure to achieve beta1 performance criteria on target hardware. Is anyone even claiming that we have achieved dogfood level on these machines? RickG, if you have someone that can act on this now, feel free to reassign it.
Peter, thanks. We will wait until we get info also from S.Gagley.
updating to S.Dagley....still waiting....running out of batteries.... Peter, in Steve's absence can we get someone else to look at this.
My team should not have this bug. Steve had it because he helped out on NSPR, but he is leaving my team. Gordon, can you take it?
Invesitgating this bug will require some amount of work to instrument the code, probably using Apple's instrumentation SDK. Understanding the issues might take some time. I would guess, however, that the issues are mostly necko-related, so it would be appropriate for gordon to look at it. I could take a look, but have no spare cycles right now.
Gordon, can you please look at this?
Assignee: sdagley → gordon
Status: ASSIGNED → NEW
Peter, did the tests you performed start with a cleared cache? We are still getting the kinks in the cache worked out, so I definitely know about some performance implications of that, but if it's simply network I/O speed, I'm not sure why we would be slower than 4.x. How should this bug be prioritized in relation to the current PDT+/crashers that I seem to be accumulating?
I've just been downloading the opt builds on the Mac, and leaving all defaults as is. It seems like the memory cache is on now, but I don't know when it was turned on. I don't think anyone here is interested in such simple stopwatch measurements anyway, although as a user, elapsed clock time is all I care about. You're getting this bug because the PDT team needs more info in order to determine whether this should be + or -
This problem seems particulary acute on <http://news.bbc.co.uk>. This site is almost unusable with Mozilla.
marking plus because perf is a top priority for m14.
Summary: loading complex (cnn.com) pages much slower on Mac → [PDT+]loading complex (cnn.com) pages much slower on Mac
Whiteboard: [NEED INFO] → [PDT+][NEED INFO]
No longer blocks: 25824
The performance analysis of mozilla vs. 4.x on Mac is important, but very involved. I'm not sure how much I can get accomplished for M14. This is likely to be an ongoing issue.
Whiteboard: [PDT+][NEED INFO] → [PDT+][NEED INFO] no estimate
It is highly likely that this bug and bug 25108 are related. We should consider marking the bugs as duplicates, but Scott and I should both continue to work on it. We would at least accumulate relevant information in one place.
*** Bug 28857 has been marked as a duplicate of this bug. ***
I filed bug 29338 -- PR_Poll needs to deal with async notification on the mac. But given scc's change to the timeout value in bug 25108, maybe we can close this now. Can someone do some basic performance analysis to verify that things are better now?
Whiteboard: [PDT+][NEED INFO] no estimate → [PDT+][NEED INFO] no estimate -- may be fixed
Adding Jan Daily to Status Summary for me to input Mac page performance increases/losses into this bug :-)
Whiteboard: [PDT+][NEED INFO] no estimate -- may be fixed → [PDT+][NEED INFO][Jan Daily]no estimate -- may be fixed
I don't think we can close this yet. I'd like to see 4.5 performance levels on <http://news.bbc.co.uk> before this is closed.
The Combo box fix in Rods's tree speeds this up by 25%, and I have a fix for bug 1248 that speed the load of this page from 18 seconds to 11 seconds (61% average). Image loading is (was) very slow, I put in some code to blit only the part of the image that has been read in.. this speeds this up considerably, since entire images are blitted over and over.. only the part of the image that is in memory is updated!!! The fix uses Pam Nunns addition of the number of lines of the image that were read in. It is an addition of 4 lines in nsImageMac.cpp, but should be tested to make sure that all is well. We can add the same enhancements for windows and Unix at a later time to minimize effects on Beta also.. should get speed improvement there also.
I tried this yesterday with 2000-03-01-09 build. It took ~45sec on my G3, 233mhz, OS 8.5, 128mg RAM to bring the page up enough to see most content. But 4 minutes later it was still loading. I would not hold beta1 for this page, but we should try to find out why it takes so long. I did not try 4.72, but I will get that data and add to this bug shortly.
Loaded this page http://news.bbc.co.uk on 4.72 and the time was 23.18 but there was a java applet on the page that got an exception error and did not load. I also cleared the cache and then restarted the browser before launching the url.
Did some tests on http://news.bbc.co.uk with my g3-350, os9, build 2000-03-01-08. initial load, refresh, 'forward' then 'back' mozilla ~12.5 secs, 3-5secs 3-5 secs NN4.72 ~6-8 secs, 5-6secs 5-6 secs IE4.5 ~5 secs <3secs instantaneous FYI NN and IE both use a RamDisk for the cache and NN has user_pref("browser.cache.memory_cache_size", 4096); added to the prefs. IE has the proxy bug fixed as well. Hope this helps.
I think we have some intranet problems here from inside the firewall. If externally a user sees load time of meiering's findings, i would not hold beta for this. Clearing PDT+ for reconsideration to PDT- for beta at Friday PDT mtg.
Whiteboard: [PDT+][NEED INFO][Jan Daily]no estimate -- may be fixed → no estimate -- may be fixed
Did a little more testing at a time with decreased intranet traffic here. Also turned Java Off for both NN and IE. Did 4 replicates, quitting program and physically deleting the cache each time. Browser bbc.co.uk cnn.com Moz 0302-08 8.7 8.5 NN4.72 6.2 5.5 IE4.5 4.0 5.0
PDT-
Summary: [PDT+]loading complex (cnn.com) pages much slower on Mac → loading complex (cnn.com) pages much slower on Mac
Whiteboard: no estimate -- may be fixed → [PDT-] no estimate -- may be fixed
Boys you ain't seen nothing yet :-) My favourite browser buster is to read the index for Java 1.1 from my hard drive. This is the Allnames.html file that you get if you click 'Index' in the 1.1 Javadoc. This file weights in at 1.1MB, and as I noted, I'm loading it from local disk. I've a 400MHz G4 with 128MB of ram, so the machine is no slouch. Here are the figures for this file: NS 4.7 = 15 seconds 11mb allocated, 18mb used Mozilla M14 = 106.52 seconds default 12mb allocated 35mb used IE5.0 for Mac (new Tasman rendering engine) Default 4mb allocated 31.4 mb used = 408seconds Match Nav4 with 11mb allocated, 31.5mb used = 373 seconds Mozilla timing from app, others by clock. Mac memory partitions are no longer absolute - apps can ask for extra TempMem, hence different values for allocated and used RAM. So mozilla is too slow, and it uses too much ram, but IE 5 is the real shocker in time terms. This is my Mac browser buster page. I won't use a browser that loads it too slowly. IE5 performs almost exactly like IE 4.5. Mozilla M14 is borderline. Nav 4 still rules this one.
Target Milestone: M14 → M15
Target Milestone: M15 → M17
Moving post beta bugs to M18 which is now the post-beta milestone.
Target Milestone: M17 → M18
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF bugs
QA Contact: paulmac → tever
Beta 1 gone, changing to beta 2. ObjectSpace JGL API doc index: 1024K HTML document (text only) PPC G4/450, Mac OS 9.0.4, Mozilla M16 2000041608 Netscape Communicator 4.7.2 - 5 seconds!!!! Mozilla M16 - 27 seconds (although it still deserves at least a P4 priority) Internet Explorer 5 - I gave up after 180 seconds (it really surprised me that IE5 was this slow) Bottom line - Mozilla already beats IE5 but (in terms of Netscape) is no improvement over the previous Netscape browser. If Mozilla rendering time could be cut in half that would probably be acceptable to most people. But the fact that it's over 5x slower in rendering a large text-only HTML document is a little concerning (I bought a G4 for speed! - the document should load faster than I can fart!) Of course, if anyone remembers the Communicator prereleases - those things were slower than...
Keywords: beta1 → beta2
Moving beta2 bugs out of M18.
Target Milestone: M18 → M17
Keywords: nsbeta2
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [PDT-] no estimate -- may be fixed → [nsbeta2-][PDT-] no estimate -- may be fixed
well lets mark the dang bug fixed, and have a partay!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
OK I re-ran my JDK 1.1 Javadoc "AllNames.html" browser buster. Moz build 2000061411 (nightly between M15 and M16). Hardware as before. Moz Memory set to 16 mb, using 23mb when idle/displaying home page, using 35mb by the time the document is loaded. Time to load from my hard disk: Range 55 to 75 seconds over 3/4 passes (quitting the browser between each test run) Donwloading the same document from http://java.sun.com/products/jdk/1.1/docs/api/AllNames.html Range between 35 and 41 seconds. So, we're 30..50% better than M14 at loading from disk, but still taking 300...500% of the time taken for NAV4 to do the same task. I'm now tempted to open a new bug along the lines of: "Mac disk loading code is slow" as it appears that mozilla takes 150...200% longer to load this document from a local file than to load it off of the network. Actually, the nature of the bug seems to have changed. The progress bar now tends to zoom up to approx. 25%, then there is a freeze, then it zooms up to 60% etc, with a really long freeze on 99% or 100%. When I say freeze I mean that the progress bar stops and the UI becomes unresponsive for 5 to 10 seconds. Looks like threading to me. Let me know what you think and I'll open a bug to track this.
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.