[cups.development] [RFE] STR #1461: minimize copying (tighten temp-space bounds) in filter pipeline where possible

[Chapman Flack]

[STR New]

Because of the sizes that print files can reach, it is worthwhile for
an infrastructure component like CUPS to be reviewed for unnecessary
copying of these files.  For example, the Software Performance
document uniformly budgets temp storage "up to size of print file"
for all backends, but for many backends that bound can be tightened
with careful design. For example, it seems that several backends
copy the stream to a file if they receive it on stdin, but this should
only be necessary in backends for protocols that require the stream
length up front. In particular, IPP does /not/ require the length up
front (RFC 2910 sec 4: An HTTP server MUST support chunking for IPP
requests, and an IPP client MUST support chunking for IPP responses
according to  HTTP/1.1 [RFC2616]) and the IPP backend could use
chunking to eliminate this copy of the file in all cases.

Even where a protocol does require length in advance, the proper test
in the backend should not be whether the input is named or stdin, but
whether the input (whether named or stdin) is a regular file or not
(using fstat(2)) so the copying can be eliminated except in the truly
necessary cases (where the input is not a regular file and the protocol
requires a length).

The design docs could probably be fleshed out with, for each backend,
a statement that its protocol does or doesn't require a copy to
be made; similarly, the design requirements for each filter could
explicitly discuss whether the filter's function could be accomplished
in pure streaming operation, or under what conditions it will require
copying.

As a related issue, there's a bit of tightening needed in the language
of the Software Performance document: temp space bounds at many
pipeline stages are described as "up to size of print file" but this
language obscures the fact that "size of print file" varies from stage
to stage ... usually not getting smaller ... and that especially when
we reach the backend the size in question can be fsck'n huge (making
the backends an obvious place to start with eliminating unnecessary
copies).

Link: http://www.cups.org/str.php?L1461
Version:  -feature