Closed
Bug 985
Opened 26 years ago
Closed 25 years ago
{perf} Performance problem with long directory listings
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: jcarpenter0524, Assigned: nisheeth_mozilla)
References
()
Details
(Keywords: perf, Whiteboard: [Perf])
- Go to URL
http://slip/projects/marvin/css/
(netscape internal location - behind firewall)
- viewer starts to list a directory of all the files in this folder, then locks
up and dies.
Reporter | ||
Updated•26 years ago
|
Component: HTMLTables → Layout
I made some performance improvements to the image frame code and it helped
some, but the real problem is that the page has some 430 images without width
and height tags. That means we end up doing 430 incremental reflows and since
the block/inline code isn't optimized yet that means a whole heck of a lot
of work.
Rick, this can't be fixed by Monday. It's not a very big problem either because
it's not common to see pages with so many images without width/height tags
A related problem which we need to address at some point is that because there
are only five or so unique images we get the size info quickly and then
generate 430 reflow commands which we then continually process until we're
finished. That's why it appears like we're hung.
Assignee: troy → kipp
Status: ASSIGNED → NEW
Summary: Crash viewer every time I go to this location → performance problem with long directory listings
I updated the title to reflect the real problem.
Also, I'm waiting on a bug fix in the parser (HR's closing PRE tags; bug #1731)
before tackling the performance issue because the parser bug makes the issue
much worse
Comment 6•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
Priority: P2 → P5
Summary: performance problem with long directory listings → {perf} performance problem with long directory listings
Summary: {perf} performance problem with long directory listings → Performance problem with long directory listings
Summary: Performance problem with long directory listings → {perf} Performance problem with long directory listings
Comment 8•26 years ago
|
||
On my Win98 machine with build 1999080312, this problem does not occur. It does
take a while to load the entire listing of directories, but it finishes loading
fine and i am able to scroll through the entire list.
I've changed the cc list to include troy; this is the ideal testcase for the
reflow-dirty optimizations we've been talking about.
Comment 10•25 years ago
|
||
With all of the current work in the content sink, block reflow optimization and
so on, the page in question now loads pretty well. So I'm changing the milestone
to later since its no longer a pressing issue.
Comment 11•25 years ago
|
||
Updating to default Layout Assignee...kipp no longer with us :-(
Comment 12•25 years ago
|
||
Nisheeth, another example of the need to reflow command coalescing
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15 → M13
Assignee | ||
Comment 13•25 years ago
|
||
Setting milestone to M13...
Comment 14•25 years ago
|
||
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were
using in the Status Summary field.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•25 years ago
|
||
This bug is fixed now that blocks and inlines are coalescing reflow commands.
The number of reflow commands generated for this page has reduced from 257 to 6.
There is a perceptible decrease in layout time of about 1-2 seconds (on a
Pentium 3, 733 Mhz, 192 MB RAM).
You need to log in
before you can comment on or make changes to this bug.
Description
•