How to optimize color parsing for NeoPixels library on arduino?

Question

Arduino

Through WebSocket I send a string with a sequence of colors for each LED to the arduino. Now colors are transmitted in hex format with 6 characters, but I plan to rewrite them to 3 character hex.

The received data is processed as follows:

char data[length - 2];
  for (int x = 2; x < length; x++) { // первые 2 символа отсекаем т.к. там тип события и разделитель
    data[x - 2] = (char) payload[x];
  }

Next, depending on the type of event, the corresponding function is called:

switch (payload[0]) {
    .......
    case 'C': // Color Array: c|FFFFFF000000..
      eventColorArray(data);
      break;
    .......
  }

Event handling function:

void eventColorArray(char* data) {
  for (byte i = 0; i < LEDS_COUNT / 2; i += 1) {
    char hex[6];
    for (int j = 0; j < 6; j++) { // первые 2 символа отсекаем т.к. там тип события и разделитель
      hex[j] = (char) data[j + (6 * i)];
    }
    unsigned long rgb = (unsigned long) strtol(hex, NULL, 16);
    byte r = abs(0 + (rgb >> 16) & 0xFF);
    byte g = abs(0 + (rgb >>  8) & 0xFF);
    byte b = abs(0 + (rgb >>  0) & 0xFF);
    strip.setPixelColor(i*2, strip.Color(g, r, b));
    strip.setPixelColor(i*2+1, strip.Color(g, r, b));
  }
  strip.show();
}

All this works more or less stably up to ±10 fps. Then the accumulated delay begins.

Part of the problem is probably in a weak Internet, because there are 234 LEDs in the tape, this is one of the reasons why I decided to send 3 character hex instead of 6 character. But also perhaps more experienced people will tell you how to optimize the "tape fill" function.

Answer 1

1) Simplify the transmission algorithm, remove the service fields to the maximum
2) Drive data in a raw binary format (what comes is what is shot into the tape), and not "human-understandable" with a bunch of transformations
3) Perhaps it makes sense to prepare several frames at a time, optimally use the data packet size of the protocol through which the data is transferred, in order, again, to save on overhead data

Answer 2

In addition to the previous - transformation on the client?
Well, by stupidly changing the board to the same ESP32, you can win a lot of iron resources so that optimization may not be needed

Answer 3

To know what to speed up, it makes sense to start by taking measurements.
For example, scatter micros () in the code and display the duration of various operations in the console.
It is possible that strip.setPixelColor itself is very slow and repeating it 234 times gives a strong dullness.
Then it may be worth cutting the tape into several pieces and using them separately, simply by stretching the wires from the arduino to the necessary parts of the tape.
As far as I remember, it is the filling that is going on there, that is, in order to light the 234th diode, you need to transfer the command over all 233 diodes, and if you divide it into 3 parts, then the filling of the tape will speed up by 2 times.
Ideally, the neopixel library can give 110 hertz on 256 diodes, in the example above I see two procedures in a row at once, which means the final frequency already drops to 50 hertz, but if there are some other operations in the code between the color setting procedures, something is there parsed from packets, or God forbid delay (), then the frequency of filling will be significantly less.