Closed Bug 80528 Opened 23 years ago Closed 23 years ago

Printing large pages incredibly slow...

Categories

(Core :: Printing: Output, defect)

All
Linux
defect
Not set
critical

Tracking

()

VERIFIED DUPLICATE of bug 77155
mozilla0.9.3

People

(Reporter: roland.mainz, Assigned: dcone)

References

()

Details

(Keywords: perf)

Mozilla 2001-05-11-08-trunk on Solaris/Linux. Problem occurs with both
PostScript and Xprint print systems - maybe cross-platform... ;-(

Loading the example URL 
http://de.search.yahoo.com/search/photos_de?p={foto}&nice=foto&z=date&n=1000
usually takes less than 45secs - but attemping to print it takes far more longer
than 20mins (!!) here (based on Xprint debug output it looks that most time is
spend before any call to the print modules are made...).
Uh-oh... this issue is far more worse than I previously thought. Sun Ultra
5/333MHz/2MB 2ndLevelCache/384MB needs nearly two hours to print that page.
Start mozilla (compiled with --enable-optimize), load example URL, print and
after printing "ps" shows how _worse_ this issue is:
-- snip --
% ps -ef | grep mozilla-bin
 mozilla  6893 17676  0 03:26:04 pts/8    0:00 /bin/sh ./run-mozilla.sh
./mozilla-bin
 gisburn 12375 17504  0 05:46:39 pts/5    0:00 grep mozilla-bin
 mozilla  6899  6893 92 03:26:05 pts/8   117:42 ./mozilla-bin
-- snip --
Severity: major → critical
confirming on linux rh62, I waited for this url for 10 min and
declared it a hang and gave up.  Maybe it takes two hours, but
that's way beyond the threshold of anyone caring.
Keywords: nsCatFood, perf
> confirming on linux rh62, I waited for this url for 10 min and
> declared it a hang and gave up.

Sure it "hangs" - AFAIK Mozilla's layout engine isn't multithreaded, see bug
61942 (IE has a significant advantage here because it can handle each window in
a seperate process/thread)... ;-((((

> Maybe it takes two hours, but
> that's way beyond the threshold of anyone caring.

Uhm... what about testing this if it takes longer than 1 hour on a 800MHz
machine ?
I assume it would be usefull to mark this a "blocker" when _fast_ machines are
still not able to print this page in a reasonable time...
I tested this with a 400MHz pentium II, I saw enough that we
have an obvious problem.  Any time past 10 min. is irrelavant,
kinda like batting in more runs when you're ahead 12-0, who cares
at that point.
> I tested this with a 400MHz pentium II, I saw enough that we
> have an obvious problem.  Any time past 10 min. is irrelavant,
> kinda like batting in more runs when you're ahead 12-0, who cares
> at that point.

1. Agreed... but having the precise value how long it takes can give us hints
how "good" the improvements by upcoming patches are...
2. Can someone check this on Win32/Mac, please ? I assume this bug is All/All...
;-(
I think this is due to some large pictures and the output ascii can make this 
very slow.  Imagelib changed so that printing will use the native size of the 
image instead of the scaled down image used by the screen.  This means that alot 
of memory can be used, and for Postscript expecially, very large PS files are 
created and sent to the printer.  This can make things very slow or even crash 
some PS devices.  I am duping this against 68865 because I think its the same 
issue.

*** This bug has been marked as a duplicate of 68865 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified.
Status: RESOLVED → VERIFIED
dcone:
I don't think this is a problem in a specific print module.
It looks like most time (~110mins in the 2hour case, e.g. 11/12 !!) is spend
_before_ the first BeginPage() in the matching print module get's called.
The final printing of pages is very fast (<=10mins for PostScript, <=7mins for
Xprint)...

Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Its not the print module.. its the loading of the image.. and then the output of 
the image can take time also.  If the native image is large.. then the image is 
re-downloaded.. this can take a ton of time.. and system resouces.  The 
Postscript module would be the most stressed.. but does is not the problem.  It 
is the size of the image downloaded.
dcone:
The example page loads in <=2mins, printing it takes ~120mins... this is is a
factor of _60_... are you really sure that this is a problem in the print module
?
Target Milestone: --- → mozilla0.9.3
you say.. It looks like most time is before the first BeginPage, this is 
correct. the majority of the time is spent loading the images.  All the images 
on this page are loaded at there native size.  Also with printing, there are two 
reflows, which means things can be loaded twice (the reason we do two reloads is 
another subject).  So with this page, I find I can wait a very long time for the 
screen to load, over 5 minutes sometimes.  Printing can take over 2x this time 
in the best of cases.  Then if your doing postscript.. the full image is 
created sent to the printer, scaled and then printed.  This can contribute also, 
depeending on the printer.  Some printers are fast, some are slow.  Anyway, I 
think the major problem with this page are the images.. which is already 
reported.. and Pavlov is looking into. We need to be able to print the cache and 
scaled images.. this will cut the time down to greater than 5 minute loads I am 
experiencing in the normal case. The bug number is 77155

*** This bug has been marked as a duplicate of 77155 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
dcone:
bug 77155 is Win2000 platform... is this the correct bug ? IF yes... bug 77155
should be Platform/OS = All/All...
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.