In the original post he had it as a byte so that wasn't necessary.
To answer the original question, and skip the intervening discussion a bit, I think your limitation comes from the fact that you are storing into a single byte (rpmcount).
Second, at 8000 RPM you have 133.33 RPM per second, so you have 1.9 seconds before wrap-around.
Meanwhile, to display (say) 8000 to the serial port at 9600 baud plus a carriage-return/linefeed would take 6.25 mS ((1/960) * 6).
At 133 interrupts per second you will get one every 1/133 mS (ie. every 7.5 mS).
I can imagine that at much over 8000 RPM the rate at which you are displaying will take more time than you have in hand. Plus you should probably clear the pending interrupt before re-enabling interrupts.
See: Gammon Forum : Electronics : Microprocessors : Interrupts
Scroll down to "How are interrupts queued?". In particular you could clear any pending interrupt like this:
EIFR |= _BV (INTF0); // clear flag for interrupt 0
I'm inclined to agree with gardner, except that I would clear the counter when interrupts are off, as well:
noInterrupts (); // critical section
count = rpmcount; // make copy
rpmcount = 0;
interrupts (); // end critical section
At low speeds, RPM is more accurately measured by getting the period (and inverting it) rather than the frequency. I discuss this here:
At 133 revs/sec you are clearly going to have around 0.75% error rate (ie. the next count would be 132 or 134). But if you measure the period with the hardware timer (or even just measure time between pulses) you would get a more precise measurement.