Closed
Bug 2611
Opened 26 years ago
Closed 25 years ago
loading complex (cnn.com) pages much slower on Mac
Categories
(Core :: Networking, defect, P5)
Tracking
()
VERIFIED
FIXED
M17
People
(Reporter: sfraser_bugs, Assigned: gordon)
References
()
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.
Reporter | ||
Updated•26 years ago
|
OS: All
Reporter | ||
Comment 1•26 years ago
|
||
This may be a combination of 2132 and 2231.
Reporter | ||
Comment 2•26 years ago
|
||
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?
Comment 4•26 years ago
|
||
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. ;)
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 8•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Updated•26 years ago
|
Priority: P2 → P5
Target Milestone: M4 → M7
Comment 9•26 years ago
|
||
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
Comment 10•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M7 → M8
Updated•26 years ago
|
Target Milestone: M8 → M9
Comment 11•26 years ago
|
||
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. ;-)
Updated•26 years ago
|
Target Milestone: M9 → M10
Updated•26 years ago
|
Target Milestone: M10 → M11
Comment 12•25 years ago
|
||
mass-moving most m11 bugs to m12
Comment 13•25 years ago
|
||
paulmac..is this still an issue?
Comment 14•25 years ago
|
||
I'll defer to simon, steve, et al on this, I'm not the one to say that whether
this is 'fixed' or not.
Reporter | ||
Comment 15•25 years ago
|
||
This is probably due in part to 18738 (slow image loading).
Comment 16•25 years ago
|
||
Mass-moving non-PDT+ bugs to M13
Comment 17•25 years ago
|
||
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Comment 18•25 years ago
|
||
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were
using in the Status Summary field.
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 19•25 years ago
|
||
moving to m14
Comment 20•25 years ago
|
||
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
Comment 21•25 years ago
|
||
PDT going to wait for data before making a beta1 call
Updated•25 years ago
|
Summary: [PP]top100 loading complex (cnn.com) pages much slower on Mac → loading complex (cnn.com) pages much slower on Mac
Comment 24•25 years ago
|
||
Let's make sure this is on waterson's perf list. PeterT: What's the disposition
of this bug?
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
Peter, thanks. We will wait until we get info also from S.Gagley.
Comment 27•25 years ago
|
||
updating to S.Dagley....still waiting....running out of batteries....
Peter, in Steve's absence can we get someone else to look at this.
Comment 28•25 years ago
|
||
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?
Reporter | ||
Comment 29•25 years ago
|
||
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.
Comment 30•25 years ago
|
||
Gordon, can you please look at this?
Assignee: sdagley → gordon
Status: ASSIGNED → NEW
Assignee | ||
Comment 31•25 years ago
|
||
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?
Comment 32•25 years ago
|
||
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 -
Reporter | ||
Comment 33•25 years ago
|
||
This problem seems particulary acute on <http://news.bbc.co.uk>. This site is
almost unusable with Mozilla.
Comment 34•25 years ago
|
||
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]
Assignee | ||
Comment 35•25 years ago
|
||
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
Assignee | ||
Comment 36•25 years ago
|
||
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.
Comment 37•25 years ago
|
||
*** Bug 28857 has been marked as a duplicate of this bug. ***
Comment 38•25 years ago
|
||
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
Comment 39•25 years ago
|
||
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
Reporter | ||
Comment 40•25 years ago
|
||
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.
Comment 41•25 years ago
|
||
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.
Comment 42•25 years ago
|
||
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.
Comment 43•25 years ago
|
||
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.
Comment 44•25 years ago
|
||
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.
Comment 45•25 years ago
|
||
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
Comment 46•25 years ago
|
||
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
Comment 47•25 years ago
|
||
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
Comment 48•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 49•25 years ago
|
||
Moving post beta bugs to M18 which is now the post-beta milestone.
Target Milestone: M17 → M18
Comment 50•25 years ago
|
||
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF
bugs
QA Contact: paulmac → tever
Comment 51•25 years ago
|
||
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...
Comment 53•25 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [PDT-] no estimate -- may be fixed → [nsbeta2-][PDT-] no estimate -- may be fixed
Comment 54•25 years ago
|
||
well lets mark the dang bug fixed, and have a partay!
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 55•25 years ago
|
||
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.
URL: www.cnn.com → http://www.cnn.com
You need to log in
before you can comment on or make changes to this bug.
Description
•