I think your question is based on the flawed premise that this is a problem. While the network is split, at most one side has sufficient validators to fully-validated ledgers, even though both sides are making forward progress. It's also possible that neither side will have a super-majority, and thus while both sides will make forward progress, neither side will fully-validated any ledgers.
Once the two sides rejoin, one chain or the other will acquire a super-majority due to avalanche of the validators as the network rejoins. This is better than not making forward progress during the split because network transaction capacity isn't lost.
During rejoin, a large number of otherwise-expensive checks are not needed. There's no need to execute transactions twice (once to decide how to vote on them and then again to determine their actual results). There's no need to retry transactions (since you know the order they executed in). And so on. All you have to do is build each ledger in the final accept process, which you need to do anyway because you need to update your databases, push transaction results to clients, and so on.