There are two pieces to this question really. One is how much time does it take to send the data to the NeoPixels. And the other is how fast can your code provide the next set of changes so they can be sent.

The wire protocol takes 1.25us per bit. If you are using a 3 element Rgb LEDs, that's 30us per pixel. Add 300us latch between updates, and a little overhead of about 100us, and this should be what to expect.
For 4 element Rgbw LEDs, its 40us per pixel.

   RGB microseconds = pixelcount x 30 + 300 + 100
   RGBW microseconds = pixelcount x 40 + 300 + 100

Depending on the "method" used to send this data, the actual time the CPU takes will vary greatly.
For most platforms, the CPU will be doing the work. So the cpu will consume time to do all the work except for the latching. So you end up with...

  RGB cpu microseconds = pixelcount x 30 + 100;
  RGBW cpu microseconds = pixelcount x 40 + 100;

Once its finished with raw data, it will return from 'Show()'. It does not wait on the latch time before returning, but it will wait on it if you call Show() again before the latch was finished being sent.

On some tests I ran for a 3000 pixel strip, I found the following:

• For the calculation, it comes out to about 90100us.
  For the NeoEsp8266BitBang800KbpsMethod, it took 91518us to send the data. 1500us more overhead than the calculation would account for.
• For the NeoEsp8266Uart800KpbsMethod, it took 89679us to send the data. This is faster due to the 128 byte hardware buffer.
• For the NeoEsp8266Dma800KbpsMethod, the default for Esp8266, it took 904us to copy the data. This is faster as it uses the hardware to send the data. But it still does have to copy the working buffer into the DMA buffer. This copying of the buffers will also vary depending on the pixel count, but now we are talking on the order of 0.7us per pixel if running at 80mhz and 0.4us per pixel at 160mhz. Once its copied, it will return from 'Show()' to let you start preparing the next frame of data.
• For AVR, it doesn't have enough memory for 3000. When I tried timing smaller counts using micros(), it showed extremely unreliable time values. This leads me to believe that micros() is not good enough for timing code and I am left with no alternative.
• For ESP32 it uses either the I2S DMA or the RMT DMA, so will also be very fast as it sends asynchronously. The time is just the copy and translation time into the sending buffer.
• For the NRF52840 (Nano 33 BLE) it uses PWM DMA, so will also be very fast as it sends asynchronously. The time is just the copy and translation time into the sending buffer.

This truly depends on how complex your sketch is. How many animations, how complex the animations, and what other things are you doing.
You can never overrun the NeoPixelBus, as the Show() will block if there is an already outstanding frame being sent or waiting for latch. If you are hitting this, then you are working faster than the time it takes to send the data to the pixels; which is as fast as you can ever get.