Taking into account the running status, you can expect an absolute maximum of 3125 new values per second. So you will have 300 instruction cycles to process a new value. Most 8052 instructions take 1 instruction cycle, but the more useful ones, like cjne and the like :P take 2 or even 3. 300 cycles should do just nicely though. When in doubt about which instruction is heavy on the cycles, consult the 8052 "bible" (you know what I mean, or else it's in "links/interesting sites", specifically chapter three).
How many times a new value is actually sent depends on (in this case) the pedal of course, its resolution, and how neat its MIDI implementation is. For instance, does it take advantage of running status at all, or does it blurt out the header again each time it has a new value to send... That would reduce the amount of new values to 1000 a second. But you should always design for the worst case, so count on 3125 new values a second.
Also, the pedal will not be operated all the time. This is where a buffer may bring some relief, but relying on a buffer means (in the case of MIDI) you are already counting on the data sporadically coming in faster than you can process it, and if you actually are finding yourself behind on processing the data, you will have more delay. IMHO, you don't need a buffer at all when dealing with simple MIDI (note on/off, program change and controller data). Also, your buffer will have to be pretty big (kilobytes) to make up for slow processing while the data keeps streaming in AND you will need to be sure the assumption that USUALLY the data will not come in faster than you can process it is true. Just design your code lean and mean, and you won't need a buffer. The example illustrates this, it takes no more than 10 or 20 instructions to process a byte and come to some sort of action, be it rejection of the message or actually doing some I/O.
A buffer is more appropriate for accumulating packets in my experience, which is hardly the case with continuous controller data, or where you can allow the buffer to be ridiculously big. Maybe with sysex messages you will have an advantage, but I've never tangled with those. The key to quickly interpreting MIDI lays more in the field of state machines in stead of buffering (as with a lot of programming problems). Search this forum: Michael Karas has once posted a good example of how to build one.
I think the example is on a disk which is currently in the office. I will get it to you as soon as I can get my hands on it again.