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.