[cups.development] ppdMarkOption/ppdConflicts performance improvement

[Hidetomo Katsura]

> No, I mean that having that many options is unreasonable and
> unusable, especially if those options are constrained in
> complex ways.
> 
> When you have 100 options, it usually means you haven't
> exposed/expressed the complexity of your driver efficiently.

why or how is it unreasonable and unusable?

those are real numbers in real product PPDs.

could we focus on cups rather than other components (driver, OS, and others)?
if there are problems in other components, they need to fix it, not on this
maling list.

if i could blame on other components, i would say why don't we just make CPU
(and I/O access) 100x faster. that would solve the problem. there is nothing
to discuss. obviously, this is not the route we should pursue.

> Please provide a link to such a PPD file.  I've never encountered
> a file that big in the 13 years I've been doing printing software.

needless to say, technologies advance whether you like it or not. things get
more and more features and options.

> Yeah, that'll slow ppdOpen() down significantly, something we are
> loath to do because it makes running a server with large numbers
> of printers infeasible (and that is a more common configuration
> than a single driver with 100 options).

you probably want to try to come up with solutions than excuses to deny ideas
that you wish to deny.

if there are two different usages, you could provide it as options using an
environment variable or whatever.

but that probably won't be necessary because, again, if you have small
numbers of options/choices as in your test cases, ppdOpen() is extremely fast
anyway, and nobody would notice.

> *If* we built a dependency graph (tree) of the constraints, we
> *might* be able to do partial updates efficiently.  However,
> that level of optimization will not happen for CUPS 1.3 (we are
> getting close to beta...)

that's fine. and you are right, it's probably too late for cups 1.3.

btw, i wasn't aware of the cups 1.1 performance issue until recently. i was
surprised that no one did anything about it for so many years on Mac OS X.

> Your Mac users should file a bug report with Apple, since that is
> the source of the performance problem, and they ultimately will
> decide what will go into future Mac OS X releases, not us.  Improving
> the performance of ppdConflicts/ppdMarkOption beyond the 5x
> improvement I've implemented for 1.3 is simply not a priority.
> Getting 1.3 out the door *is*.

yes, they have been filing bugs and complaining directly to Apple for a long
time but Apple doesn't do anything.

oh, and i was told that you have a great influence to Apple, so if you tell
them to improve their print dialog code, they probably will. also if you tell
them to take the improvement i made to cups 1.1.23 on Mac OS X 10.4.x, they
might consider doing something about it for the existing users who won't
upgrade to Mac OS X 10.5 when it's available (most of our customers never
upgrade their Mac OS X. if they have 10.4 now, they will have 10.4 forever).

i'm not unreasonably pushing any of this for 1.3. i don't care if it's in 1.4
or 1.5. i'm just making suggestions because there is an immediate need for
performance improvement in real world usage, and there are so much more (and
some simple things) you can do to improve it significantly.

thanks,
katsura