Palettes: Bad performance on 0.14.* and later

[jw2013]

What happened?

I discovered, that previous WLED binaries on ESP8266 were running at 80 MHz instead of 160 MHz.
Using it a lot, so I tested the newer _160 releases for my d1-mini's, but they were actually much slower!
String with 600 LEDs (WS2815) was now running at 13 FPS, instead of the 20 FPS using e.g. the 0.13.3 release.

So I curiously compiled 0.13.3 using board_build.f_cpu = 160000000L, and performance went up to 25 FPS. Nice!

But why do the new releases perform so badly? I compiled basically all 0.14.* sources, and discovered that performance went downhill going from 0.14.1-b2 to 0.14.1-b3. Only real code change here was in json.cpp, and that one indeed causes the performance issue.

To Reproduce Bug

Install firmware 0.14.1-b2 and 0.14.1-b3 to compare.
Setup LEDs with power limiter (WS2815), 600 LEDs (WS281x), Effect Glitter. Check FPS in info.

Expected Behavior

Expected to keep the nice FPS rate.

Install Method

Self-Compiled

What version of WLED?

WLED 0.14.1-b2 and WLED-0.14.1-b3

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[jw2013]

@blazoncek , why did you add the "cannot reproduce" label? It is super simple to reproduce this!
For your convenience, please find attached example cfg.json and presets.json files.

wled_presets.json
wled_cfg.json

600 LEDs, WS281X, using Glitter effect, on a regular ESP8266EX D1 mini module.

Using the release binaries provided here, I get the following results:

WLED_0.13.3_ESP8266.bin => 21 FPS
WLED_0.14.1-b2_ESP8266.bin => 12 FPS
WLED_0.14.1-b3_ESP8266.bin => 8 FPS

(self compiled WLED_0.13.3_ESP8266_160.bin => 25 FPS)

This is not just a minor performance issue, I hope you agree?
And replacing all ESP8266 and ESP8285 with ESP32 modules is NOT the correct fix.

[jw2013]

One further update, also checked the performance of the first release after 0.13.3, which would be 0.14.0-b1:

WLED_0.14.0-b1_ESP8266.bin => 16 FPS

But then I made a nice discovery: When changing to a different palette, FPS went up to 20 FPS, so similar to 0.13.3. Analyzed this further, turns out that the framerate drops tremendously once the "Power Limiter" kicks in! This was not the case in earlier versions. @blazoncek , any idea? Next I'm going to check the source code changes of that part.

[jw2013]

The power limiter seems not be the reason, it just causes a drop of about 2 FPS, but that's the same for 0.13.3 and 0.14.0-b1.
But the actual palette makes the big difference in 0.14.0-b1:

• Default runs with 20 FPS
• Colors run with 16 FPS
• April Night runs with 12 FPS (!)
• Rainbow Bands runs with 20 FPS

On 0.13.3, the selected palette has zero influence on the FPS, all run with 21 FPS.
Any ideas?

[blazoncek]

I'm only considering current 0_15 branch for anything that would need investigation.
So test on 0_15 branch, please.

[jw2013]

Ok, I will do that! Btw, for 0.14.0-b1, I have found the issue:

The performance issue is caused by Segment::color_from_palette in FX_fcn.cpp. It calls loadPalette for each single call of color_from_palette, which is causing a high CPU load (except for palettes 6, 7, 8, 9, 10, 11 and 12, as those are always kept in memory)!

Quick fix, using a paletteCache, renders the same performance as the 0.13 series!

CRGBPalette16 curPalCache;
int curPalCacheIndex = -1;

uint32_t Segment::color_from_palette(uint16_t i, bool mapping, bool wrap, uint8_t mcol, uint8_t pbri)
{
  // default palette or no RGB support on segment
  if ((palette == 0 && mcol < NUM_COLORS) || !_isRGB) {
    uint32_t color = currentColor(mcol, colors[mcol]);
    color = gamma32(color);
    if (pbri == 255) return color;
    return RGBW32(scale8_video(R(color),pbri), scale8_video(G(color),pbri), scale8_video(B(color),pbri), scale8_video(W(color),pbri));
  }

  uint8_t paletteIndex = i;
  if (mapping && virtualLength() > 1) paletteIndex = (i*255)/(virtualLength() -1);
  if (!wrap) paletteIndex = scale8(paletteIndex, 240); //cut off blend at palette "end"
  CRGB fastled_col;

  if (transitional && _t) {
    fastled_col = ColorFromPalette(_t->_palT, paletteIndex, pbri, (strip.paletteBlend == 3)? NOBLEND:LINEARBLEND); // NOTE: paletteBlend should be global
  }
  else {
    if ( curPalCacheIndex != palette ) {
      loadPalette(curPalCache, palette);
      curPalCacheIndex = palette;
    }
    fastled_col = ColorFromPalette(curPalCache, paletteIndex, pbri, (strip.paletteBlend == 3)? NOBLEND:LINEARBLEND);
  }

  return RGBW32(fastled_col.r, fastled_col.g, fastled_col.b, 0);
}

[jw2013]

Basically same problem in 0.15 and main branch.
color_from_palette always calls currentPalette, and currentPalette first calls loadPalette.

To give you an idea, just using the cache made it go up from 12 FPS to 24 FPS. So the current implementation spends half of its time in loadPalette calls :-/

[softhack007]

And replacing all ESP8266 and ESP8285 with ESP32 modules is NOT the correct fix.

Well for me that's a debateable (and acceptable) option 😉 I'm not saying everyone has to agree. But here's my personal reasoning:

• With 600 leds on a single pin, the theoretical max performance would be ~55fps. I've seen esp32 delivering 64 fps on 512 LEDs with one output. It looks like 8266 cannot even get close to this.
• esp32 are availeable for cheap, plus 8266 will not be supported by espressif in less than 2 years from today (hardware end-of-life)
• programming for 8266 is like torturing yourself: 8266 has a single tasking framework, it's always low on RAM, and you literally need to invent new hacks every few weeks to keep it working. Additionally, 8266 support sometimes hinders developing new cool stuff on esp32.

So that's my personal perspective as a developer in a small team, and we devs usually do not receive anything in return for our commitment to WLED. At the same time, everybody wants to have a say about "what is the correct way". Sorry you are not the first (or the last) - but I really had to blow off some steam. tl;dr you've hit a nerve.

Feeels better now 🤓 So back to technical...

Technicially, the palettes problem you have discovered seems to affect all platforms. Maybe it's worse on 8266, but esp32 could also benefit from an improvement 👍 so thanks for your investigations.

[jw2013]

I understand the reasoning from a personal pov, but don't necessarily agree to all points, as my personal requirements might differ a lot. I really appreciate all the work you put into WLED, and all the new features it got so far! Thanks a lot!

I've created a pull request for 0_15, but compared to earlier versions, that branch does not work nicely on ESP8266 (yet).
Therefore I will also create a pull request for 0.14.3, the fix makes it run with >25 FPS again, on the 'ancient' hardware, with 600 LEDs.

One more performance issue with 0.14.3 (might be the same case for 0.15): When the power limiter forces a lower brightness, it loses about 50% of its FPS. I have found the reason already, and a quick hack resolves it, but still working on a clean solution.

Hope that helps a bit!

[vPrapo]

@softhack007 I want to thank you for all your efforts and I totally respect your opinion.
I agree with you to an extent and yes I would certainly replace old ESP devices with newer ones for better performance and support since they're cheap and worth it.
However, some devices that are not DIY (manufactured) are not easy to mess with or replace, flashing the firmware alone by overwriting the propriety firmware that has no option to OTA is a big hassle and feels a big achievement when done well and safely for e.g some E27 bulbs in the market are built with old ESP devices and they give no choice to easily upgrade the ESP chip or flash into WLED without soldering/de-soldering or so, despite how it's assembled like some are made to not be opened or closed tightly for protection with glue or whatever so there are risks and possibilities to break it or fry components while doing soldering jobs.
So without background in electronics and technical knowledge it's not easy at all to achieve.

Replacing tens of bulbs can cost too much for the whole house and that isn't a practical fix in terms of both convenience and cost.. unless of course to replace only the dead ones, for my case I do have bulbs that are hard to reach and needs very high ladder size that I usually rent and tell the workers nearby for help since it's not safe distance.

I know that many things can be fixed in a hacky way and this isn't very practical or actually need to sacrifice some features to make something else works, I agree this takes time and doesn't help the software as a whole, just certain devices but.. in the same time It's kinda definitive that maxing the possibilities of an old device is challenging and most likely will open the eyes to few things that we are not aware of without facing problems such as new ways of better memory management and optimizations which normally might not come to mind with powerful devices such as esp32 because everything seems to work flawlessly.. unless we are facing issues like this one now that in return bring optimizations to the whole software.

@jw2013 Special thanks for your great find.

I do really appreciate all of your guys efforts.

[robertlipe]

@softhack007 : "programming for 8266 is like torturing yourself" - totally understood and agreed. Heroic efforts to keep bringing new features to old hardware just has to stop at some point. They're not rewarded. At some point, it just doesn't fit.

At the risk of being one of those that wants a say (I don't think I have any code in this project), I'll offer what's worked for many projects: Pick a point in the project and formally (and loudly) pull the plug. Version numbers are cheap. Make one that counts. Add #if defined esp8266 (or whatever) #error "Here's a nickel kid, get yourself a better computer" and link to the Dilbert cartoon. You can't stop anyone from removing that and trying to build it on their own or forking it, but after that, you can just aggressively close things as 'unsupported platform' and it's no longer YOUR problem. As devs, we've all had do to this for VAX, Win95, NT3, Qt3, SunOS 4, K&R C, i386, Python 2, and other 'OMG, this HAS to live forever' platforms. Even non-free software development doesn't have infinite resources to keep things alive forever.

I get the arguments about e-waste and $3 boards (do yourself a favor and choose replacements with PSRAM.) needing techs (that usually cost > $3) to install them, changes in assembly lines, SKUs, or whatever, but 2016 boards are happiest running 2016 code. It just can't fit forever - whether that's bytes of SRAM, Flash, microseconds in an interrupt handler, jitter for frame refreshes, or whatever. Staying on old code is an option.

Sometimes, we must trim the branches of the shrubs of the gardens we maintain so that overall growth and life can thrive.

Happy Hacking,
Jack Kevorkian

P.S. That said, the analysis and premise of #3979 seems pretty sound...and since a message came in while I was typing, I'll clarify I'm not unsympathetic to that POV, either. You can make tiny changes to old branches (for a little while) that can improve those and hopefully have enough resources that everything isn't the proverbial straw on the camel's back. Need 32 bytes for an extra block? Hopefully you blew the whistle in time to still have it and BEFORE that branch picked up some new feature that they may not need anyway. My fundamental point is that there needs to be a reasonable feature/functionality freeze so new LED support and new JSON support doesn't take those last straws.