DC - Add MIME sink pattern reuse cache.

[chri50]

Based on #1382

So, I have worked on the cupsFilter instead of the entire PPD cache.

Share an identical incoming filter graph to the same sink (normalising printer/* → printer/sink) and reuses the computed supported MIME type list instead of recomputing it per printer. Uses a canonicalised, sorted edge signature (super/type, cost, maxsize, program hash) hashed. Reduces scheduler startup and printer addition overhead when many printers have identical filter chains; safe fallback when disabled or on cache miss.

Core testing results:
Base: opencups 2.4.7 with mime sink pattern applied , set up 6947 printing queues with four different PPD.

Before: ~32 minutes
After:   ~10 seconds

[chri50]

With CUPS_MIME_SINK_REUSE=1, store for reuse by future printers (same sink incoming edges)

Please let me know, what you think about.
Thx.

[michaelrsweet]

OK, so I'm going to spend a bit more time reviewing these changes. Some initial impressions:

1. I like the more general implementation and reduction in algorithmic complexity.
2. I'm wondering whether we could take advantage of the cupsArray API's hashed array support rather than re-implementing a hashed storage container.
3. In a similar vein, optimizing the implementation of mimeFilter* which has a rough complexity of O(n^4) would dramatically improve overall performance for the non-cached cases.
4. I wonder if it would be worth saving the cache and keep track of the mtime or hash of .types and .convs files?

Finally, whatever we end up with we'll just leave it turned on.

[michaelrsweet]

I've taken the liberty of updating the MIME unit test program (testmime.c) so we can do some isolated profiling/tuning:

[master 2fb742f] Update MIME unit test:

The current CUPS 2.5 code seems to take about 0.3ms to generate the array of source types for a given PPD on my MacBook Pro (M4 Max), 0.75ms on a Raspberry Pi 5.

[chri50]

I really appreciate your feedback, thx!

• I'm wondering whether we could take advantage of the cupsArray API's hashed array support rather than re-implementing a hashed storage container.

I'll take the cupsArray advice into account.

• In a similar vein, optimizing the implementation of mimeFilter* which has a rough complexity of O(n^4) would dramatically improve overall performance for the non-cached cases.

I thought caching would be more defensive approach. You're right, the growth of the graph database and the increase in runtime per printer is a tough topic. I'm curious if there is still such a topic in CUPS 3?

• I wonder if it would be worth saving the cache and keep track of the mtime or hash of .types and .convs files?

I assume you're talking about precompiling the mime graph when cups starts. It depends a lot on the specific setup and i think it will provide more drawbacks than benefits.

Thank you for your support.

[michaelrsweet]

@chri50

• In a similar vein, optimizing the implementation of mimeFilter* which has a rough complexity of O(n^4) would dramatically improve overall performance for the non-cached cases.

I thought caching would be more defensive approach. You're right, the growth of the graph database and the increase in runtime per printer is a tough topic. I'm curious if there is still such a topic in CUPS 3?

CUPS 3 is largely based on PAPPL 2.0, which offers a much simpler filter architecture without chaining. The complexity of building the supported document formats is only O(n) there - one loop through the filters, and we list anything that converts to the printer's native format or to PWG Raster (image/pwg-raster) which is the "internal" raster format we use for the "drivers" there whether the printer takes PWG or Apple (image/urf) raster.

• I wonder if it would be worth saving the cache and keep track of the mtime or hash of .types and .convs files?

I assume you're talking about precompiling the mime graph when cups starts. It depends a lot on the specific setup and i think it will provide more drawbacks than benefits.

My gut agrees but wanted to put it out there.