If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in mozilla1.9beta2

Status

()

Core
Graphics
P2
normal
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: Smokey Ardisson (offline for a while; not following bugs - do not email), Assigned: Stuart Parmenter)

Tracking

({perf, regression})

Trunk
mozilla1.9beta2
PowerPC
Mac OS X
perf, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

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....
Blocks: 334721

Comment 1

11 years ago
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.

Comment 5

11 years ago
fixed by 367433
Status: NEW → RESOLVED
Last Resolved: 11 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

Comment 8

10 years ago
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...?

Comment 10

10 years ago
(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

Comment 15

10 years ago
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-

Comment 16

10 years ago
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.

Comment 18

10 years ago
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.
(Assignee)

Comment 19

10 years ago
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

Comment 21

10 years ago
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

Updated

10 years ago
Assignee: cbarrett → nobody
Status: REOPENED → NEW
Component: Widget: Cocoa → GFX: Thebes
Flags: blocking1.9? → blocking1.9+
QA Contact: cocoa → thebes

Comment 22

10 years ago
(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

Comment 23

10 years ago
I figured performance was a blocker for Tp and Ts, didn't know it was for things like printing. Good to know.
(Assignee)

Updated

10 years ago
Priority: -- → P2
(Assignee)

Comment 24

10 years ago
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

Comment 26

10 years ago
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)

Updated

10 years ago
Assignee: nobody → pavlov
Target Milestone: --- → mozilla1.9 M10
(Assignee)

Comment 27

10 years ago
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
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.