Is the technique at the end of this documentation useful? Alternatively, I’ve avoided many of the performance pitfalls using a fluent interface to declaratively state which entities in a given transaction for sure won’t change vs. might change (immutable vs. immutable). For example, if the entities I am saving are aggregate roots in which the root or its entities refer to “refdata” items, then this heuristic prevents many writes because the immutable items don’t need to be tracked. The mutable items all get written without check (a weakness… One which may or may not be acceptable).
I’m using this with a generic repository pattern precisely because I don’t want to track changes or implement a specific strategy for each case. If that’s not enough, perhaps rolling your own change tracking outside of the context and adding entities in as needed will work.