Optimizations to consider

[RobTillaart]

fillValue()

fillValue is rather inefficient performance wise. It first set all values to zero and then value is added N times, with all overhead of addValue.

optimized fillValue proposal

• program size 8010 - 7876 = 134 bytes more! (quite a bit)
• performance gain 1512 => 64 micros (a lot)

Testing to do

• fill whole array
• fill partial array
• number == 0 ?

void RunningAverage::fillValue(const float value, const uint16_t number)
{
  uint16_t s = number;
  if (s > _size) s = _size;
  for (uint16_t _index = 0; _index < s; _index++)
  {
    _array[_index] = value;
  }
  if (_index == _partial) _index = 0;  // faster than %
  _min = value;
  _max = value;
  _sum = s * value;
  _count = s;
}

stddev() stderr()

stderr depends on stddev so room for gain if both are needed. Thoughts to consider:

• caching the value adds performance (dirty flag)
• calculating them both in one call is more efficient

[RobTillaart]

As fillValue() seems less used (typical only at startup) as far as I know, it will not be replaced as PROGMEM is more precious (UNO) than a one time speed optimization.

I leave a copy in the code for now so people can use it . An option could be to rename it and add it as a function like fillValueFast(), but in the end it feels like a premature optimization.

[RobTillaart]

ra_performance.ino Size: 7876 var 546 bytes (UNO)

Performance RunningAverage lib: 0.4.1
...
    getStandardDeviation    : 1852
    getStandardError    : 1920

Caching version Size: 7994 var 550 bytes

Performance RunningAverage lib: 0.4.1
...
    getStandardDeviation    : 1856
    getStandardError    : 76

Speed-up is a 1800++ microseconds (in 2nd call) at the price of 118 bytes progmem + 4 bytes RAM The second time getStandardDeviation() (hidden in getStandardError) is called it responds from cache.

Note: any add() or clear() call clears the cache, so the gain is only there if one calls both or one of them multiple times. As the user can cache the values themselves if they want to it feels like a premature optimization.