16622 - [PERF] extremely slow displaying pages with many unloadables

Status: VERIFIED DUPLICATE of bug 11702

(Core :: Layout, defect, P3)

Description

[Sean Richardson]

Summary:
If a webpage includes many IMGs whose SRCs cannot be loaded, a very long time
(several tens of seconds for ~70 images) may elapse before any more of the
page is displayed, during which mozilla.exe is completely unresponsive
(all windows), the CPU is maxed out, and all other applications are
sluggish.

This will typically happen if a page that uses partial URLs (either
relative or absolute) to avoid repeating "http://www.sitename.com/"
at the beginning of every SRC URL is saved to a local machine without
all the images (or adjusting the URLs). It could also happen if the
page belongs to a site with a separate images server that is unresponsive
or poorly responsive.

To Reproduce:
1. Open Task Manager and minimize it to see CPU load during test (NT)
   (or equivalent for another platform).
2. View the "66 unloadable images" testcase attachment to this report
   and start timing.
3. Observe the scrollbar: quickly, the bar portion shrinks to about
   one quarter of the scrollbar (for a ~700 pixel tall window, ymmv)
   and then, about once every second or two, it shrinks by another
   pixel.
4. Observe the CPU meter in the taskbar tray: it will stay pegged
   until the page displays.
5. Click once or twice in the lower part of the scrollbar.
6. Wait some more, and note the duration when the page displays. The
   page will scroll now based on the step five click(s).
7. Go back to this page and view the "66 loadable images" testcase.
8. In a second or two you should have your page.

Result:
The "66 unloadable images" testcase (based on the Communicator version of the
Bug 7732 URL) takes tens of seconds to display, and evidently much is
going on under the hood. The [STOP] button does not stop processing.
The "66 loadable images" testcase, identical except that the IMG SRC URLs
have been made complete, displays almost immediately.

(The table showing numbers for fifty companies will also have 50 lines
with nothing more than "1x1trans" in them. This is a distinct bug, but
see the speculation below)

Expected:
The "66 unloadable images" testcase takes at most a few seconds more
than the "66 loadable images" testcase to load. It will take some time
to determine that the images are not coming, so the timing could not be
identical.

Following is an extract from an Apache 1.3.9 log running on Windows NT,
showing the GETs for the unloadable images. Note that "1x1trans.gif"
appears 50+ times in the page, but it was only requested once. Note also
that all four GETs took place within 3 seconds.

127.0.0.1 - - [17/Oct/1999:01:54:43 -0400]
"GET /inc/images/1x1line.gif HTTP/1.0" 404
331 "-" "Mozilla/5.0 [en-US] (WIN95; I)"

127.0.0.1 - - [17/Oct/1999:01:54:45 -0400]
"GET /testcases/images/jubak6.gif HTTP/1.0" 404
336 "-" "Mozilla/5.0 [en-US] (WIN95; I)"

127.0.0.1 - - [17/Oct/1999:01:54:46 -0400]
"GET /inc/images/star1.gif HTTP/1.0" 404
329 "-" "Mozilla/5.0 [en-US] (WIN95; I)"

127.0.0.1 - - [17/Oct/1999:01:54:46 -0400]
"GET /testcases/1x1trans.gif HTTP/1.0" 404
331 "-" "Mozilla/5.0 [en-US] (WIN95; I)"

Speculation:
If the behaviours noted in Bug 16619 and Bug 16621, where unloadable IMGs are
given their filenames as substitute ALTs, after Gecko reserves their
dimensions and then removes the box for those dimensions, takes even a second,
it could be the root cause of this bug. This would be congruent with the
behaviour noted in step 3 above, if the 50 rows in the table meant to be
1-pixel spacer lines each had to be resized one-by-one, thrice:
(a) to make room for the height of "1x1trans" (1 pixel)
(b) to remove the reservation for the height of "1x1trans"
(c) to make room for the height of the string "1x1trans"

Occurs on:
1999-10-15-11-M11 on Windows NT.

Comment 1

[Sean Richardson]

Attachment: 66 unloadable images in a saved HTML file

Comment 2

[Sean Richardson]

Attachment: 66 loadable images in a massaged saved HTML file

Comment 3

[Sean Richardson]

It seems that both Bug 16619 and Bug 16621 are considered DUPLICATEs of
Bug 1994 (which is a frankenbug if I've ever seen one). Reading Bug 1994, and
also Bug 5764, the discussion tends to support the speculation in the original
report: if an image cannot be loaded, the filename is used as the ALT text,
and the ALT text becomes inline.

Of course, at that, there is no good reason why doing that to 66 images
would take over a minute.

Comment 4

[troy]

DUP of 11702. Table incremental reflow performance

*** This bug has been marked as a duplicate of 11702 ***

Comment 5

[Chris Petersen]

This is a duplicate of 11702.