Snapshots do not directly affect the mirroring session. To allow the principal to continue, the mirror must harden the log, not commit. This simply means the received log from the principal must be written and persisted into the log files.
It is the recovery process that continuously applies the log to the mirror that will have to handle the copy-on-write required to maintain the snapshot, when it applies the changes in the log to the data. This process can lag behind the principal, it is not required to be up to the current principal LSN position.
That being said, maintaining the snapshot does incur IO, Memory and CPU overhead, which will reflect in the overall performance of the mirror hosting instance. There will also be the additional query workload that will be supported by the snapshot. So obviously, in this sense, having a snapshot causes overhead on the mirror which diverts resources from the task of keeping up with the principal (receiving, processing and hardening the log). But it is not true that a snapshot incurs direct overhead. The principal does not have to wait for the copy-on-write required by the snapshot to occur.