how to decide between choosing different types of containers?

Question

I am writing a software for an embedded platform (ARM11) that runs Linux. This software is supposed to work for prolonged periods (months) of time without being closed / reopened and with mostly every embedded platform the RAM is scarce (250 Mega Bytes total for OS and user programs). This device is connected to another device through serial port and they communicate together continuously (every 300 milliseconds) in form of a ping for status, errors, alarms etc. This device is used for access control on a gate in a high traffic area where over hundred people will cross it using MIFARE cards as a means of identification. I thought about using dynamic containers to hold objects that hold communication packets and card data (because they can have different size from a few bytes to one kilo bytes) of-course this objects will be constantly created and destroyed and they won't stay for a long time (withing a function scope). My language of choice is C++ and I'll be using Qt for the libraries. also all the elements of data are unsigned 8 bit characters.

• won't using such containers cause memory fragmentation problem?
• since the maximum size for the containers is known wouldn't it be better to use C type containers like arrays and structs for better performance?
• Is there a rule of thumb for choosing the appropriate containers?

EDIT: mifare cards contain 1 kilo byte of memory (1024 bytes) that are divided to 16 sectors of 4 * 16 bytes blocks each. On a read operation a minimum of one block of data is returned and I will need to extract as low as one bit of information from this block and the way I search the data obtained from the contactless cards would be through parameter files supplied to my program that clarifies the mapping and masks of the card data.

Answer 1

The main challenge in these conditions is memory fragmentation. A major cause is mixing object sizes in allocations, and freeing them at different times. There are effective techniques to combat that.

For starters, if you have many small objects of a fixed size (say 28), a dedicated allocator for that size objects will help. It cannot cause real fragmentation itself, you just have a bitmap of free blocks and to allocate you can just pick the first free block.

For strings, it can make sense to round up their sizes, eg to a multiple of 2 and just pad out the data with \\0 . You can then have dedicated allocators for sizes 8/16/32/64/etc. You'll waste no more than 100% and in practice it's closer to 40% (depends on string length distribution). For short strings, use the small string optimization - check if std::string and/or QString use it, if not using your own string type may be advisable.

C type containers such as a malloc 'ed array typically do quite poor, precisely for the reason mentioned above: too easy to generate them in any random length. std::vector typically grows in nice fixed increments. However, check if it rounds reserve requests up to sane amounts (power of 2, or multiple of 4KB, whatever is smaller). If not, you should.