In general, a standalone notary will perform better than a notary cluster. Why? The purpose of having a cluster is to provide fault tolerance, and that involves replicating each transaction commit to all (or majority) members of the cluster.
For example, in case of Raft, all client requests are serviced by the leader node, and replicated to followers. However, the leader cannot commit the request and send back a response to the client until it knows the majority of the followers have acknowledged it. A single transaction commit will require multiple communication roundtrips in the clustered scenario, as compared to a single roundtrip in case of the standalone notary.
Now, coming back to your question, your first choice will result in three notary services with no fault tolerance, and the second one in a single replicated notary service. In terms of pure performance, the combined transaction throughput for the three standalone notaries will probably be more than threefold to that of the single replicated notary.
However, a single transaction can only contain states assigned to a single notary. If you want to build a transaction with states assigned to different notaries, you have to first reassign them to the same notary. That involves creating an extra "notary change" transaction that effectively just changes the notary pointer for a state (more accurately, it consumes the state, and creates a copy with the new notary pointer).
Setting fault tolerance aside, the three notary scenario works best if there are three fairly isolated groups of parties that mostly transact among each other, and each group gets assigned a different notary. Transactions from different groups can then be processed in parallel. However, cross-group transactions will incur an extra cost of requiring additional "notary change" transactions, which will diminish the performance benefits. In theory, if inter-group transactions are as frequent as intra-group transactions, the performance difference between having one or three notary services would be minimal.
As for the transaction processing distribution, it's not expected or advised for a single CorDapp to use more than one notary, for the reasons above. For notary clusters, requests from clients get distributed to replicas in a round robin fashion (depending on the consensus algorithm, the replicas may still forward all requests to the leader!).
Crash fault-tolerant consensus algorithms (Raft, Paxos) will almost always be faster than Byzantine fault-tolerant ones (PBFT/BFT-Smart, HoneyBadgerBFT, Hashgraph), since they require fewer communication steps.
