Performance in animations for longer strips

[flonatur]

Hi Michael, first let me thank you for the awesome library, it is finally a lib which does not crash after some hours of operation on my microcontrollers. I used the adafruit "original" lib for running animations on NodeMCU / Wemos D1 controllers but found out that they tend to reset after some time when under heavy load, like for updating 200 LEDs every 20ms. So the NeoPixelBus is stable to a point where it does work reliably without crashes.

But.

I found out that designing a loop which updates every pixel individually with the built-in methods is painstakingly slow, up to a point where it is not usable for my animations anymore. I have a setup with 250 LEDs which I want to update, and assigning new values with a loop using the RrbColor constructor like this slows down the whole thing that i have update frequencies at approx. 5 Hz, which does not look smooth anymore:
for (int i=0; i<numpixels; i++) { strip.SetPixelColor(i, RgbColor(newR, newG, newB)); } strip.Show();
This for-loop alone takes 20..30 ms.

I was at a point that I wanted to revert back to the adafruit library but was annoyed by the resets, and just about throwing it all out and retire everything.
Then I remembered that I learned from another nerd friend of mine that using constructors is taking a lot of time, so I tried to assign the RGB values to the exposed members directly and this worked like a charm. So having a pixel map like this
RgbColor pixel[numpixels];
updating their values and then just copying them to the strip like this
for (int i=0; i<numpixels; i++) { pixel[i].R = newR; pixel[i].G = newG; pixel[i].B = newB; strip.SetPixelColor(i, pixel[i]); } strip.Show();
And the loop runs like .. well .. perfectly fast. - Me happy.

I was looking at the source of your library and saw that you're using this "constructor" pattern a lot in th builtin methods, so I was wondering if I am doing something wrong with the first approach. Do you not experience this kind of slowing down?

Best, Flo

Video of my little nerd-lamp:
https://user-images.githubusercontent.com/10893989/112278549-40298780-8c83-11eb-85ce-633beeaa879d.mp4

[Makuna]

What platform are you building for? 20ms to do that work on ANY Arduino platform doesn't make sense; there is something else going on.

Please provide a minimum sketch that can demonstrate the problem; since what you typed above is a fragment and can imply other issues and solutions. No need to include any timing capture unless the platform inherently supports cycle counting as I will just put in a IO PIN high/low and use a logic analyzer to capture timing.

Having the object initialized at another time like your buffer suggestion, should be no different in timing if you correctly include that code into the timing equation. Actually, it should be worse, as now there is an extra copy for pixel data. Again, without a concrete example to demonstrate the problem, it is hard for me to say what a solution is; BUT constructor initialization is not inherently inefficient.

[flonatur]

You are right, there was something else going on. I spent a whole evening refactoring and trying to reduce the sketch to a minimum which still shows the problem. Now I am more confused than ever because not only I did not find the source of the slow code, but also could not reproduce it anymore with my original approach, which uses the constructor method. So your hint that this method usually works efficiently was enough for me to somehow untangle the project. I guess this is how development sometimes works. :)
Thanks again!