Stack vs heap in embedded context - Performance Comparison
When working with embedded C, knowing how stack and heap memory behave helps us understand how fast our program runs.
We want to see how the time to allocate or free memory changes as the program runs.
Analyze the time complexity of memory allocation on stack vs heap.
// Stack allocation example
void func() {
int arr[100]; // allocated on stack
// use arr
}
// Heap allocation example
#include
void func() {
int* arr = malloc(100 * sizeof(int)); // allocated on heap
// use arr
free(arr);
}
This code shows two ways to allocate memory: one on the stack and one on the heap.
Look at what happens when memory is allocated or freed repeatedly.
- Primary operation: Memory allocation and deallocation
- How many times: Each time func() runs, allocation happens once
Allocation on stack is very fast and stays almost the same time regardless of size.
| Input Size (n) | Approx. Operations (Stack) | Approx. Operations (Heap) |
|---|---|---|
| 10 | Very few (simple pointer move) | More (search free block) |
| 100 | Very few (same as 10) | More (depends on fragmentation) |
| 1000 | Very few (same as 10) | Even more (longer search) |
Stack allocation time stays almost constant; heap allocation time grows with size and fragmentation.
Time Complexity: O(1) for stack allocation, O(n) for heap allocation
This means stack allocation is very fast and predictable, while heap allocation can take longer as more memory is used.
[X] Wrong: "Allocating memory on the heap is always as fast as on the stack."
[OK] Correct: Heap allocation involves searching for free space and managing fragmentation, which takes more time than simple stack pointer moves.
Understanding stack vs heap speed helps you write efficient embedded code and answer questions about memory management clearly.
"What if we used a custom memory pool instead of the standard heap? How would the time complexity of allocation change?"
Practice
Solution
Step 1: Understand local variable storage
Local variables inside functions are temporary and exist only during function execution.Step 2: Identify stack usage in embedded C
The stack is used to store temporary data like local variables and return addresses.Final Answer:
On the stack -> Option AQuick Check:
Local variables = stack [OK]
- Confusing heap with stack for local variables
- Thinking local variables are stored in flash
- Assuming all variables are in CPU registers
Solution
Step 1: Recall malloc syntax
malloc returns a pointer to allocated memory, so pointer variable is needed.Step 2: Check each option
int *p = malloc(sizeof(int)); correctly assigns malloc's return to an int pointer. Others misuse types or syntax.Final Answer:
int *p = malloc(sizeof(int)); -> Option CQuick Check:
malloc returns pointer, assign to pointer [OK]
- Assigning malloc result to non-pointer variable
- Using sizeof without malloc
- Incorrect function call syntax
Solution
Step 1: Understand stack size limits
Stack size is limited in embedded systems; large local arrays consume stack space.Step 2: Consequence of large stack allocation
Allocating large arrays locally can exceed stack size, causing overflow and crash.Final Answer:
Stack overflow may occur causing a crash -> Option AQuick Check:
Large local arrays risk stack overflow [OK]
- Assuming heap is used automatically
- Thinking large arrays go to flash
- Believing compiler auto-converts locals to globals
void func() {
int *p = malloc(10 * sizeof(int));
// ... use p ...
// missing free(p);
}
What is the main problem here?Solution
Step 1: Analyze malloc usage
Memory is allocated on the heap with malloc but never freed.Step 2: Identify consequences of missing free
Not freeing heap memory causes memory leak, wasting limited embedded memory.Final Answer:
Memory leak because allocated heap memory is not freed -> Option DQuick Check:
Missing free causes memory leak [OK]
- Confusing stack overflow with memory leak
- Thinking malloc syntax is wrong
- Assuming pointer is uninitialized
Solution
Step 1: Evaluate stack usage for large buffer
1KB local array uses half the stack, risking overflow in embedded systems.Step 2: Consider heap allocation safety
Allocating 1KB on heap with malloc is safer; heap is larger and managed manually.Step 3: Compare global and static arrays
Global/static arrays use fixed memory but reduce flexibility and increase RAM usage always.Final Answer:
Use malloc to allocate 1KB on the heap and free after use -> Option BQuick Check:
Heap allocation safer for large temporary buffers [OK]
- Using large local arrays risking stack overflow
- Ignoring freeing heap memory
- Assuming global arrays are always best
Ready to prove it?
Pass the test and this pattern moves unknown
