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.

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.

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.

@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.

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.

I rewrote the mime-sink-pattern to adopt the cupsArray features and simplify the cache hit method, as well as eliminate unnecessary memory waste.

Current E2E testing shows significant performance improvements similar to those seen in the first attempt.

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

@chri50 Thanks for this, I'm head's down on some other stuff ATM but will circle back to this in the next day or so.

OK, so I'm finally taking a fresh look and I want to further simplify this. The vast bulk of your current PR is code to calculate a hash of the different filters' values to avoid re-running mimeFilter over N file types, and honestly the result is pretty hard to follow/maintain.

I'm thinking about having a parallel array that tracks destination media types with a list of source types, so we can build out a list of supported document formats more quickly. For this we don't need to worry about cost or max size (it is just answering the question "will it blend?" and not how) and it would provide caching behavior...

Try current Github master:

[master 1150b02] Add a new mimeGetFilterTypes function for getting the list of supported document formats for a printer. The new algorithm is O(n log n) vs. the old O(n^4) (Issue #1392)

The new algorithm executes an order of magnitude faster on my M4 Max MacBook Pro and two orders of magnitude faster on my 10th Gen Intel Dell XPS 13 and a Raspberry Pi Zero 2W. Let me know how it works for you...