Thank you for your answer, Igor.
I appreciate the fact all these options are possible (conditional Preliminary matching, Automatic, Preliminary and Manual matching).
I didn't mean to suggest a change in this regard. Just highlighting an option I use, and making sure the logic behind it is sound :-)
Gain a second here, a second there (I also switch from Fuzzy & Hits to Fuzzy in TM options), and you get a system more responsive for large resources, even allowing the luxury of Greedy exact matches!
> is there any drawback?
I don't think there is any drawback. In modern hardware the processor can handle a few thousand translation units really fast with the Preliminary matching option off. With smaller translation memories, there might be no noticeable difference. CafeTran has an option in Preferences > Memory tab which triggers the Preliminary matching automatically after a set number of translation units (the threshold) is reached. I agree with your point in general but there are users (especially with fast Mac computers) who seem to prefer a second or two processing delay for the current segment with the Automatic matching, instead of waiting for the Preliminary matching to complete and have no delay at all.
Since the content of a read-only TM is not being modified, does it make it sense to systematically apply Preliminary matching to read-only TMs?
If one does so, is there any drawback?
From what I understand, you get all Preliminary matching advantages (quicker matches, no additional system load after the initial matching) without any of its disadvantages (no accounting for changed TM TUs).
Is that true?