How to Measure RTOS Performance
There are a number of factors that affect the memory footprint of an RTOS.
The CPU architecture is key. The number of instructions can vary drastically from one processor to another, so looking at size figures for, say, PowerPC give no indication of what the ARM version might be like.
Embedded compilers generally have a large number of optimization settings. These can be used to reduce code size, but that will most likely affect performance. Optimizations affect ROM footprint, but also RAM if the code is copied. Data size can also be affected by optimization, as data structures can be packed or unpacked. Again both ROM and RAM can be affected. Packing data has an adverse effect on performance.
Most RTOS products have a number of optional components. Obviously, the choice of those components will have a very significant effect upon memory footprint.
Most RTOS kernels are scalable, which means that, all being well, only the code to support required functionality is included in the memory image. For some RTOSes, scalability only applies to the kernel. For others, scalability is extended to the rest of the middleware.
Different people have different ideas about what scalability means. Fine grain scalability means that only the core of the RTOS [the scheduler etc.] and the code for the service calls that are actually used are included in the final memory image. There should be no redundant code.
Although an RTOS vendor may provide or publish memory usage information, you may wish to make measurements yourself in order to ensure that they are representative of the type of application that you are designing.
These measurements are not difficult. Normally the map file, generated by the linker, gives the necessary memory utilization data. Different linkers produce different kinds of map files with varying amounts of information included in a variety of formats. Possibilities extend from a mass of hex numbers through to an interactive HTML document and everything in between.
There are some specialized tools that extract memory usage information from executable files. An example is objdump.
The importance of RTOS memory footprint must be understood, as its implications may be non-obvious.
As mentioned earlier, memory is always an issue with embedded systems, but the detailed priorities vary from one system to another.
A small system may only have limited on-chip memory and, of course, the application code must be accommodated. Hence, the RTOS must be as small as possible.
A bigger system may not have such a pressure on total memory space. System performance is more likely to be the priority. This means that the peak performance is required from the RTOS, so placing it into on-chip memory or locking it into cache may be attractive. Both of these options are most feasible if the kernel size is minimized.
If the system copies code from flash to RAM, it is particularly important to understand the memory space requirements.