ESP8266 Community Forum

- Fri Oct 30, 2015 7:57 pm #32648 Hi,
I have been writing a sketch that performs a SOAP web service request and returns data....lots of text data that I wish to store.
My hope was that I could use allocated char * vs fixed size char arrays to save memory.
Unfortunately I noticed that my free ram was declining at an alarming rate when allocating the strings.
Although I only have a total of 2k of text strings spread across 150 strings, that at the end of the allocation my heap had gone down by almost double that. So I wrote a small test program (below) and noticed something alarming (at least to me).
The overhead of allocating a 1 byte is 23 bytes of heap. The program below shows that the overhead varies between 16 bytes at minimum and 23 bytes at maximum depending on the number of bytes allocated. Unfortunately most of the strings I am trying to store are less then 32 bytes so my overhead is huge.
Is this a problem with memory allocation on the ESP8266 or normal for a microprocessor? I should try it on the Uno but have not had a chance yet.
What do you think?

Thanks
Mark

Code: Select allconst int MAX_SIZE=100;
char *saveit[MAX_SIZE];

void setup()
{

  Serial.begin(115200);
  delay(5000);

  for (int loop = 1; loop < MAX_SIZE; loop++)
  {
uint32_t freeHeapStart = ESP.getFreeHeap();
    saveit[loop] = new char[loop];
uint32_t freeHeapEnd = ESP.getFreeHeap();

Serial.print("new size=");
Serial.print(loop);
Serial.print(", alloc=");
Serial.print(freeHeapStart - freeHeapEnd);
Serial.print(", overhead=");
Serial.println((freeHeapStart - freeHeapEnd) - loop);
  }
}

void loop() {
  // put your main code here, to run repeatedly:

}

- Sun Nov 01, 2015 1:09 am #32714 At the moment we still use memory allocator from Espressif IOT SDK. It is actually a slightly modified version of heap4.c from FreeRTOS. This allocator uses 4 words per heap node (which is 16 bytes). So if you request n bytes, 16 + ((n + 3)&3) bytes are taken from the heap.
Out of 4 words only 2 are actually used, so by replacing the allocator with a custom one this may be reduced down to 8 + ((n + 3) & 3) bytes.
For your use case I would suggest rolling your own memory pool based allocator.