It's great that you want to be efficient, but I think you are barking up the wrong tree here by wanting to clear the serial buffer "slightly faster".
The device you mention sends 's', 'n', 'p' followed by a packet type, some data, and two bytes of checksum.
Now let's say that in a particular case you get 's', 'n', 'x' instead. So you realize there has been an error and clear the buffer. However the sending device doesn't know that. So it is still sending packet type, data, checksum etc.
Now you start reading again, but you get . Oh no! Still not 's', 'n', 'p'! So you clear the buffer again. And try again. Then you get the checksum! Egads! Still not 's', 'n', 'p'! So you see, clearing the buffer "really fast" achieves nothing. In fact you have no really reliable way of knowing when all the "bad" data has arrived. Short of building in a nice long delay. Which itself is not efficient.
The only really reliable way of handling serial comms is to "take it as it comes". Just keep looking for the start of packet marker. After all, you can't pull it in any faster than the other end sends it out, so that is not at all inefficient.