Memory Layout Comparison Array vs Linked List in DSA Rust - Complexity Comparison
We want to understand how accessing elements in arrays and linked lists differs in speed.
How does the way memory is arranged affect how fast we can get data?
Analyze the time to access elements in array and linked list.
// Access element at index i in array
fn access_array(arr: &[i32], i: usize) -> i32 {
arr[i]
}
// Access element at index i in linked list
fn access_linked_list(head: &Option>, i: usize) -> Option {
let mut current = head;
let mut count = 0;
while let Some(node) = current {
if count == i {
return Some(node.value);
}
current = &node.next;
count += 1;
}
None
}
struct Node {
value: i32,
next: Option>,
}
This code shows how we get the i-th element from an array and from a linked list.
Look at what repeats when accessing elements.
- Primary operation: For array, direct access by index; for linked list, walking through nodes one by one.
- How many times: Array accesses once; linked list accesses up to i times to reach element.
Accessing an element in an array stays quick no matter the size.
Accessing an element in a linked list takes longer as the index grows.
| Input Size (n) | Array Access Steps | Linked List Access Steps |
|---|---|---|
| 10 | 1 | Up to 10 |
| 100 | 1 | Up to 100 |
| 1000 | 1 | Up to 1000 |
Pattern observation: Array access time stays the same; linked list access time grows linearly with index.
Time Complexity: O(1) for array, O(n) for linked list
This means arrays let us get any element instantly, while linked lists take longer the further we go.
[X] Wrong: "Linked lists are always faster because they use pointers."
[OK] Correct: Following pointers one by one takes time, so accessing elements is slower than arrays.
Knowing how memory layout affects speed helps you choose the right data structure for your task.
What if we added an index cache to the linked list? How would that change the time complexity?
Practice
array and a linked list?Solution
Step 1: Understand array memory layout
An array stores all its elements in a continuous block of memory, so elements are next to each other.Step 2: Understand linked list memory layout
A linked list stores each element separately in memory, and each element has a pointer to the next, so elements are scattered.Final Answer:
An array stores elements contiguously in memory, while a linked list stores elements scattered with pointers. -> Option DQuick Check:
Array = contiguous, Linked list = scattered with pointers [OK]
- Thinking linked lists store elements contiguously
- Confusing pointers usage between arrays and linked lists
- Assuming arrays use pointers between elements
Solution
Step 1: Identify fixed-size array syntax in Rust
Rust fixed-size arrays require type and size:[type; size].Step 2: Check each option
let arr: [i32; 5] = [1, 2, 3, 4, 5]; useslet arr: [i32; 5] = [1, 2, 3, 4, 5];which is correct fixed-size array syntax.Final Answer:
let arr: [i32; 5] = [1, 2, 3, 4, 5]; -> Option CQuick Check:
Fixed-size array syntax = [type; size] [OK]
- Using vec! macro for fixed-size array
- Missing type and size in array declaration
- Using tuple syntax instead of array
struct Node {
value: i32,
next: Option,
}
fn main() {
let node2 = Node { value: 20, next: None };
let node1 = Node { value: 10, next: Some(Box::new(node2)) };
println!("{} -> {} -> None", node1.value, node1.next.as_ref().unwrap().value);
}
What is the printed output?Solution
Step 1: Understand node creation and linking
node2 has value 20 and no next node. node1 has value 10 and points to node2 via Box.Step 2: Trace the print statement
Prints node1.value (10), then node1.next's value (20), then "None" for end.Final Answer:
10 -> 20 -> None -> Option AQuick Check:
Linked nodes print values in order: 10 then 20 [OK]
- Confusing order of nodes
- Expecting None printed as value
- Thinking ownership causes compile error here
struct Node {
value: i32,
next: Option,
}
fn main() {
let node1 = Node { value: 10, next: None };
let node2 = Node { value: 20, next: Some(Box::new(node1)) };
println!("{} -> {} -> None", node1.value, node2.value);
}
What is the main reason for the compilation error?Solution
Step 1: Analyze ownership of node1
node1 is moved into Box inside node2's next field, so node1 cannot be used after move.Step 2: Identify error cause
Because node1 is moved, any further use or move causes compile error "use of moved value".Final Answer:
Use of moved value: node1 is moved into node2 and cannot be used again -> Option AQuick Check:
Ownership moved node1 causes compile error [OK]
- Thinking Box inside Option is invalid
- Assuming missing lifetimes cause error here
- Believing print syntax is wrong
Solution
Step 1: Consider access pattern and memory layout
Arrays store elements contiguously, so accessing by index is O(1) and cache-friendly.Step 2: Compare linked list access and memory use
Linked lists store elements scattered with pointers, making index access O(n) and less cache efficient.Final Answer:
Array, because elements are stored contiguously allowing fast index access and better cache usage. -> Option BQuick Check:
Contiguous arrays = fast index access [OK]
- Assuming linked lists are faster for index access
- Thinking linked lists use less memory for large data
- Believing arrays cannot store large data efficiently
Ready to prove it?
Pass the test and this pattern moves unknown
