Closed Bug 362325 Opened 18 years ago Closed 17 years ago

[cairo] printing is 82% slower than pre-Cairo

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: alqahira, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: perf, regression) 

STR:

1. go to www.google.com
2. Cmd-P, return
3. Wait...

Printing (from pressing return until the page comes out of my venerable HP LJet 5MP) takes 2 mins 10 secs in Cm 2006-11-29-05; in Cm 2006-11-24-01 (the previous trunk nightly I have lying around; Cm wasn't Cairo then) took 40 secs.

The printer's old, my PowerBook is old, AppleTalk is old, and AirPort is slow, but they're all constant, so printing is slower by some order of magnitude....
cbarrett - can you look into this when the printing situation for cairo/cocoa gets straightened out?
Sure. The patch is on this bug, if anyone wants to test: https://bugzilla.mozilla.org/show_bug.cgi?id=367433

I think it will be a huge speed up -- before we were writing to a PDF and then spooling that PDF to cups.
Assignee: joshmoz → cbarrett
I'll try to build+play with that patch tonight :)
This should be fixed with bug 367433 landed.
fixed by 367433
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
FWIW, printing now takes 30 secs on this setup :) except the output is completely blank :( (filed bug 368933 on that)
So, now that we can print again, we're about twice as fast as the last time we could print, but it's still about 50% slower than before cairo-cocoa printing.

For reference:

CaminoTrunk-2007-03-27-22: 1 min 6 secs to print www.google.com
CaminoBranch-2007-03-28-04: 42 secs to print www.google.com

(the latter being almost the same number as the pre-cairo-cocoa printing trunk nightly I printed before).

I'm going to reopen this since that still seems significant.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: [cairo] printing is extremely slow → [cairo] printing is 50% slower than pre-Cairo
The speed of print preview has recovered compared with before. 

Mac OS X 10.3.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a6pre) Gecko/20070630 Minefield/3.0a6pre

Hiro, that was a Cairo 1.4.10 build, right, so when Cairo 1.4.10 finally lands for good, this should be better...?
(In reply to comment #9)
> Hiro, that was a Cairo 1.4.10 build, right, so when Cairo 1.4.10 finally lands
> for good, this should be better...?
> 

2007-06-29 nightly build was tried. 
(previous version of cairo)

Time until print preview is completed is almost the same. 
(It is about 25 seconds. )

In initial cairo build, the completion of preview was one minute or more. 


Can we close this as fixed?
I'll get some numbers this weekend since I've been the "control" data here, but my guess is we're probably good (sorry, I've been busy lately).
I spent about a half-hour today testing this while my network was quiet again, and I'm still getting the same numbers as in comment 7 :(  Actually, the trunk numbers are varying a little more wildly than before.

CmTrunk-2007-07-13-00: low 1:06, high 1:50, avg 1:23
Minefield-2007-07-14-04: low: 1:08, high 1:40, avg 1:24

For a control, I ran a few branch tests interspersed with the trunk tests, and they are consistent with my branch tests in comment 7 (which in turn are consistent with trunk pre-Cairo times from comment 0).

CmBranch-2007-07-14-00: 44 secs
Fx2005: 46 secs

Also, I noticed that the printer starts spooling up its engine/fuser at about 20secs on branch and 40-50-60secs on trunk, which seems to confirm it's taking two-to-three-times as long to get the data on the trunk (with 20secs for the actual pulling the paper and printing on it being constant).
Also, if bug 375572 were fixed, we could have a useful (timeable) way to compare processing times on the actual Mac and see if that data tells us anything (though I suspect they're about 2x on trunk what they were on branch).
Flags: blocking1.9?
Keywords: perf
blocking1.9- since the speed of printing won't block release, but of course we're really like to see this fixed
Flags: blocking1.9? → blocking1.9-
To clarify, the slowdown would have to be more then 50% in order to block release.
Just to clarify, a 50% burst in bad printer perf isn't considered blocking? But a 51% burst *would* be considered blocking? I'm not sure I agree with that.
Obviously I wasn't speaking literally in terms of a 1% difference. I'm not saying we don't want this fixed badly, but that doesn't necessarily make it a blocker.
going from 45 seconds (already way too slow imho!) to a minute and a half is unacceptable
Using the numbers in comment 13, this is really an 82% regression. Re-requesting blocking.
Flags: blocking1.9- → blocking1.9?
Summary: [cairo] printing is 50% slower than pre-Cairo → [cairo] printing is 82% slower than pre-Cairo
I was basing my decision on the fact that being slower here doesn't break any functionality, it is merely annoying. Also, I don't know how slow were before. If we're already way too slow then that is a different issue that just the 50% regression.
Flags: blocking1.9? → blocking1.9-
Summary: [cairo] printing is 82% slower than pre-Cairo → [cairo] printing is 50% slower than pre-Cairo
Flags: blocking1.9- → blocking1.9?
Summary: [cairo] printing is 50% slower than pre-Cairo → [cairo] printing is 82% slower than pre-Cairo
Assignee: cbarrett → nobody
Status: REOPENED → NEW
Component: Widget: Cocoa → GFX: Thebes
Flags: blocking1.9? → blocking1.9+
QA Contact: cocoa → thebes
(In reply to comment #21)
> I was basing my decision on the fact that being slower here doesn't break any
> functionality, it is merely annoying. Also, I don't know how slow were before.
> If we're already way too slow then that is a different issue that just the 50%
> regression.
> 

Just to be clear for future bugs.  Performance *is* a blocker:

http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/3261a73e2c920c49/130386bc44ce3c36#130386bc44ce3c36


I figured performance was a blocker for Tp and Ts, didn't know it was for things like printing. Good to know.
Priority: -- → P2
I just posted a patch in 375750 which may speed this up.
Good news; Stuart's patch in bug 375750 helps *a lot* here.

Since my old PB is still running 10.3 (and since google.com helpfully is showing a special logo for Halloween :P), we can't directly compare numbers from before, but I ran a series of tests with today's Camino branch, today's Camino trunk, and my static/opt Camino trunk build (default mozconfig) with Stuart's patch on my MBP.

Numbers were very consistent, within the error of the human eye and stopwatch:

CaminoBranch: 43 secs (19 secs until the fuser started to fire)
CaminoTrunk:  63 secs (38 secs until the fuser started to fire)
CmTrunkPatch: 46 secs (22 secs until the fuser started to fire)

So we're still a bit slower than before (Stuart notes we're still a bit bigger than before with PDFs)--and probably more noticeable on slower Macs--but we're much more in-line with branch perf. :)
Depends on: 375750
Yay... !
Just hitting 'preview' for the google.com page went from 14 secs to 4 secs on my PowerBook G4 10.4.10 ppc. (with Preview.app not running). Google.co.jp is a bit slower, but not much.

Printing to PDF is also much much faster (I'll try to come up with numbers later, time allowing).
File sizes are slightly bigger than Camino 1.5.2 & WebKit (8kb on a text-only 3 page document, but the same doc printed from an unpatched Camino trunk is twice the size).
Assignee: nobody → pavlov
Target Milestone: --- → mozilla1.9 M10
fixed by 375750.  we might be a tiny bit slower now, although we support a lot of new things like transparency now.  if anyone still sees us being really slow on any pages, file new bugs
Status: NEW → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.