Closed
Bug 2254
Opened 26 years ago
Closed 25 years ago
Large text page takes 10x longer to lay out on Mac
Categories
(Core :: Layout, defect, P1)
Tracking
()
VERIFIED
FIXED
M7
People
(Reporter: sfraser_bugs, Assigned: pierre)
References
()
Details
(Whiteboard: [Perf])
The large text document at <http://warp/tools/qa/history/tests/
biggerjoblist.html> lays out in about 1 minute on Windows (fast Pentium II),
and over 10 minutes on a Mac (300 MHz 604). In fact, it took so long that I
didn't have the patience to wait, though I did verify through MacsBug that
it was still doing stuff when I killed it 10 mins after loading the URL.
Assignee | ||
Updated•26 years ago
|
Assignee: sdagley → sfraser
Assignee | ||
Comment 1•26 years ago
|
||
I think it's a duplicate of #2211.
Reassigned to Simon.
Reporter | ||
Comment 2•26 years ago
|
||
I don't think this is a dup of 2211. I was seeing after some optimizations I made
to the font handling calls. I suspect that this performance difference is simply
because malloc() is slower on Mac, but I have still to investigate.
sujay/elig - another one...compare against Linux too. Though it does look like
Mac is hating life :-)
Reporter | ||
Comment 5•26 years ago
|
||
Changed URL to a file that is almost 1Mb in size, and a more practical test file.
Reporter | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 6•26 years ago
|
||
Accepting
Assignee | ||
Updated•26 years ago
|
Summary: [PP] Large text page takes 10x longer to lay out on Mac → Large text page takes 10x longer to lay out on Mac
Assignee | ||
Comment 7•26 years ago
|
||
Per discussion with RickG, we don't need to consider this a PP bug.
Updated the title.
Reporter | ||
Comment 8•26 years ago
|
||
It worries me that such performance differences are not considered platform
parity. If we don't at least understand these problems now, then they will be
much harder to address in future. The longer they remain, the more rigid the
whole structure becomes, and it becomes more difficult to make the kinds of
changes that may be necessary to address performance parity issues. I'd like
to put this back on [PP].
Summary: Large text page takes 10x longer to lay out on Mac → [PP]: Large text page takes 10x longer to lay out on Mac
I'd like QA to do some minimal performance testing on 01/19. I am putting this
back on the [PP] list whilst we try to figure out why the Mac is so slow. It is
affecting our ability to test properly.
Assignee | ||
Comment 10•26 years ago
|
||
In our (short) discussion with RickG, we concluded that the most important thing
during the Platform Parity Push was to have a correct display and the same
features on the 3 platforms in order to allow the XPToolkit and XPApp teams to
perform their job. Then the persons who are working on platform-specific issues
inside the Raptor team (like Don, Patrick and myself on the Mac, or Ramiro et al
on Unix) can address long term problems such as performance. The Platform Parity
effort is fairly limited in time and it was for us more a question of efficiently
allocating the resources that have been lent to us by the other teams during this
short period rather than prioritizing the problems on an absolute scale.
Performance has always been one of the main goals for the product.
Of course if you consider that the performance is so bad that the QA team can't
do their job, you can put it back in the PP list but as far as this bug goes,
it's about a file that already takes 1 minute to render on Windows: not really an
everyday task.
Assignee | ||
Comment 11•26 years ago
|
||
I just tested with the 1Mb file (http://slip/res-lib/morte1.htm) on a 225Mhz. It
takes about 30 seconds to render it after a resize but much longer (something
like 1mn 30s) to load it the first time. I noticed that this first load goes
slower and slower. If you look at the status bar, you can see the 16K blocks
being loaded very quickly at the beginning, then at an interval of a couple of
seconds around 500K and more afterwards.
Amongst possible explanations:
- an XP problem where layout re-parses everything for each block
- the memory allocator needs to be tweaked on the Mac
Still, there is a problem with Raptor because the resize is synchronous and on a
file that long, we can't block the machine during the relayout. QA: could you
verify that problem on a Window machine and open a bug report if needed?
Comment 12•26 years ago
|
||
beppe, can you try Win95. paulmac, try win 98.
Assignee | ||
Comment 13•26 years ago
|
||
I confirm that this problem comes from the memory allocator on the Mac: as we
parse the data, we spend more and more time in
nsSmallHeapChunk::GetSpaceForBlock(). Simon, did you port on Raptor the memory
allocator that you have done for Nova?
QA: If you see that the resize of a large document is a blocking operation on
Windows too, could you report it in a separate bug report? Thanks.
Reporter | ||
Comment 14•26 years ago
|
||
Yes, I did port the memory allocators from Nova to raptor, but because realloc
is almost never called now (since new & delete have no equivalent) then some of
those optimizations will be lost.
I'm working on this today.
Comment 15•26 years ago
|
||
Actually, not only is the re-size blocking on Windows, but the initial load is
also blocking. Who should get this bug for Windows?
Assignee | ||
Comment 16•26 years ago
|
||
Kipp is the man. Could you CC me on the bug report? Thanks!
Comment 17•26 years ago
|
||
Bug 2498 filed to kipp for windows specific case.
Reporter | ||
Comment 18•26 years ago
|
||
I've checked in the memory allocator changes that are the main reason for this
slowdown. I'll leave the bug open until I'm sure that there are no other low-
hanging fruit on this one.
Comment 19•26 years ago
|
||
Inserting Milestone info.
Comment 20•26 years ago
|
||
Setting all current Open Critical and Major to M3
Comment 21•26 years ago
|
||
Putting on [Perf] radar.
Updated•26 years ago
|
Summary: [PP]: Large text page takes 10x longer to lay out on Mac → Large text page takes 10x longer to lay out on Mac
Comment 22•26 years ago
|
||
Taking off the [PP] list. Some of the performance difference may be explained by
the different UI behavior between the platforms. Using the public release 2/19
Win32 build on my PPro 200 system it takes about 21 seconds to display the test
file (morte1.htm) but there is no feedback a page is loading other than the title
of the window changing. Using a debug build from 2/19 on my Mac (a PTPro w/
266MHz G3) it takes about 32 seconds to finish loading the file but there is
continuous feedback (text appears, scroll bar updates/resizes).
Comment 23•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
|
Target Milestone: M3 → M4
Comment 24•26 years ago
|
||
changing to M4 milestone
Reporter | ||
Updated•26 years ago
|
Assignee: sfraser → pierre
Status: ASSIGNED → NEW
Reporter | ||
Comment 25•26 years ago
|
||
Pierre, do you want to own this, and look at it in your performance week?
Comment 26•26 years ago
|
||
rickg, can this be improved anymore for 70% Dogfood?
Assignee | ||
Comment 27•26 years ago
|
||
Almost nothing can be done before Sunday. I'm planning to work on it the last
week of March (22-26).
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•26 years ago
|
Target Milestone: M4 → M5
Assignee | ||
Comment 28•26 years ago
|
||
Changed target to M5
Assignee | ||
Updated•25 years ago
|
Target Milestone: M5 → M6
Assignee | ||
Comment 29•25 years ago
|
||
Changed traget to M6: this cannot be fixed now because Layout doesn't render long
texts properly on Mac and Windows.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M6 → M7
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 30•25 years ago
|
||
Layout now renders long texts properly on the Mac (Windows is still broken) and I
could do some testing. The page takes about 20 seconds to display on a G3/233:
it's better than my old Windows machine but not quite as good as Communicator 4.5
(7 seconds).
Anyhow, the original problem ("10x longer to lay out on Mac") has been fixed.
Layout is still slower than Communicator to render long files but that's a
different story (#4957 assigned to Kipp).
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 31•25 years ago
|
||
Fixed in the June 1 Build.
You need to log in
before you can comment on or make changes to this bug.
Description
•