So I want the absolute highest possible refresh rate on this project because that means I do not have to filter the results as much and therefor are able to let it have a funny pulse flashing behavior with quick moves.

First a short note on the MPU6050 sensor, it transmitted the raw acc and gyro values in ~1700 us both on the UNO and Teensy, but I have reduced that time to ~300 us by rising the I2C rate from 100 kHz to 800 kHz with the help of the Teensy specific i2c_t3 library. It was actually possible to pull up the speed even more but the sensor is only specified for 400 kHz, and I prefer some stability and time savings wasn't as large after that point.

So lets talk about the pixels now, with some unprofessionally measured speeds for the show() or equivalent method, like this:

    t = micros();
    pixels.show();
    Serial.println(micros()-t);

So what really surprised me was the FastLED performance which was a lot worse than the others, despite what I read before trying it out. Do note that this doesn't include the efficient math routines that FastLED apparently has. In my case that doesn't matter, all my pixels have the same color and I only do a simple HSL conversion for finding the Hue in the accelerometer values, constant saturation, and gyro values for Luminance.

Funny thing is that it seams the UNO actually is faster than the Teensys when it comes the raw updating of the LEDs. Count in the sensor readings, color conversion and I hope soon Twitter notifications and the Teensy will be worth it, or should I just have developed it around the ESP8266 with braked out pins? (I will say no on this because, Im now able to reset the ESP and when necessary without affecting the motion based lightning). Websockets and MQTT proved a lot more difficult to get working than I suspected, been trying out several now and all of them have had their quirks so far..