In CUPS system, pstoraster filter outputs massive debug messages to stderror while printing. It degrades printing performance, even if debug logging is turned of by CUPS configuration. In our measurement, it affects mainly on FPOT (first print out time - time to hit "start" key to first page is printed). With a low-end laser printer, FPOT is 42sec with an OpenOffice.org word document (5 pages). With modified pstoraster, which dumps output to stderr to /dev/null, FPOT is improved to 32 sec - about 30% faster. Please consider to remove "-dDEBUG" option in the pstoraster script, or some other countermeasures.
Seems very reasonable to me. We probably need to remove 'mike@easysw.com' from the automatic assignment here and change it over to Ralph. Assigning to Ralph.
Till: can you comment on what cups uses the stderror output of pstoraster for, and what can be removed?
The stderr output serves only for conveying status and error information to the log files of CUPS (error_log and page_log). For me logging also lokks exaggerated and it is really possible that the CUPS raster output device uses more CPU time on logging than on its actual work. The "-dDEBUG" in pstoraster and pdftoraster are really not necessary.
(In reply to comment #3) > The stderr output serves only for conveying status and error information to the > log files of CUPS (error_log and page_log). For me logging also lokks > exaggerated and it is really possible that the CUPS raster output device uses > more CPU time on logging than on its actual work. > > The "-dDEBUG" in pstoraster and pdftoraster are really not necessary. My question was probably, what is the minimum debug stderr output needed, for CUPS's status/error info tracking to still work correctly?
Re-assigning bugs which still have work to do.
Fixed in SVN rev. 11630.