Kinda random question… As discussed previously I’m playing with forking FastLED for some updates to the AllPixel firmware as plan on updating the brightness control in a way that doesn’t really mesh with the direction of FastLED. One of the biggest pain points I had with the AllPixel firmware was that, because of the templating, every protocol I loaded ate up RAM even if it wasn’t being used. Any advice for pulling the protocol classes out of all the templating so that only the one I’m using is actually loaded into RAM? I never really pursued this before because I didn’t want to modify FastLED at all, but now I plan to do exactly that 
Are you referring to system ram or program flash? Because if program flash, there’s nothing you can do about it. If system ram, I’m assuming that right now you’re using addLeds in a switch statement or some such. You can, instead, create the lower level controllers yourself - the template parameters will still need to be compile time constants, but you can say something loosely like:
addLeds(new APA102Controller<DATA_PIN,CLOCK_PIN>(), leds, NUM_LEDS);
System RAM. And I am creating the low level controllers directly: https://github.com/ManiacalLabs/AllPixel/blob/master/Firmware/Firmware.ino#L114
But I still noticed that the more controllers I add the more system RAM is used up. I have a routine in the firmware to detect remaining available RAM and then limit the number of LEDs based on that. All my tested showed that every time I added a new controller (even manually like I’m doing) the total possible pixel count went down.
And a big thing I’m running into now is that the AP firmware is based on FastLED 3.0.x but when I tried to update to 3.1.5 the RAM usage was even higher for the same controller count. So I currently have no way of updating to the latest FastLED while keeping the same 700 max LED count.
Ah - I wonder if it’s virtual function table information - that would likely have to go into ram - and not a whole lot that can be done about that without re-architecting the whole thing and/or changing how C++ compilers do the function table layout and such.
Ah… hmm… That’s unfortunate. I may see if I can simplify things at least a little to get some RAM back. I actually could completely remove the templating for the pins, type, and channel order and be happy… just depends on how much work that is 
The templating isn’t what’s affecting the virtual function table size - it’s the virtual functions in the CLEDController class and its subclasses. Also dynamic memory allocation on arduinio’s can be dicey - as there’s overhead necessary to track what ram is allocated where. You might be better off making everything, including the max number of LEDs, static and not using new/malloc anywhere. Or, if you don’t want to make them static you could use a trick called “placement new” — make a static array of bytes that is large enough to hold the largest controller object (they should be close in size to each other though) — then you can cast that to a pointer of the specific controller type you want and use placement new to call the appropriate constructor. This won’t remove the vtable issue but it would mean you wouldn’t have ram used for all the static instances and you’d also get rid of the malloc memory overheads.
Btw this is why I put a fair bit of work into making sure that fastled didn’t use new or malloc anywhere in the first place 