Arrays
debt(d5/e3/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list Blackfire and php-meminfo as tools — these are profiling/memory-analysis tools that can reveal inefficient array usage (e.g., array_shift in loops, excessive memory from large numeric arrays). Default linters won't flag these; it requires specialist profiling to notice the performance impact.
Closest to 'simple parameterised fix' (e3). The quick_fix suggests replacing PHP arrays with SplFixedArray for numeric datasets, which is a localized refactor — swapping the data structure and adjusting access patterns. Common mistakes like array_unshift in a loop require replacing with a queue or linked list, which is a small but multi-line change within one component. Not a one-liner, but not cross-cutting either.
Closest to 'persistent productivity tax' (b5). PHP arrays are fundamental and ubiquitous across all contexts (web, cli, queue-worker). The hash-map-disguised-as-array nature pervades the entire codebase. Every developer must understand the performance characteristics. While you don't need to replace all arrays, the misunderstanding about their nature creates a persistent tax on performance-sensitive code paths across many work streams.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field is explicit: 'PHP arrays are arrays' — developers coming from C, Java, or any other language expect contiguous memory, O(1) index access with no hash overhead, and no key-value semantics. PHP arrays are actually ordered hash maps, which fundamentally contradicts the mental model from virtually every other mainstream language. This leads directly to the common mistakes (assuming array_shift is cheap, not realizing the memory overhead vs true arrays).
Also Known As
TL;DR
Explanation
True arrays (C-style) store elements contiguously in memory — index access is O(1) because element address = base + (index × element_size). PHP arrays are actually ordered hash maps, not true arrays, which is why they support mixed keys and O(1) key lookup. Dynamic arrays (ArrayList, Python list) resize by doubling capacity when full — amortised O(1) append. Understanding the difference explains why array_push() is fast but array_unshift() is O(n), and why a PHP array with integer keys 0..n behaves differently from one with gaps.
Common Misconception
Why It Matters
Common Mistakes
- array_unshift() in a loop — O(n) reindex on every call; use a queue or prepend to a linked list.
- Using PHP arrays for large numeric datasets — SplFixedArray uses ~60% less memory for integer-keyed arrays.
- Assuming count() is O(1) — it is in PHP (cached), but in other languages it may traverse the structure.
- Copying large arrays by value — PHP arrays are copy-on-write, but explicit assignment in loops still causes copies.
Code Examples
// O(n²) — array_unshift in a loop reindexes entire array each time:
$result = [];
foreach ($items as $item) {
array_unshift($result, $item); // O(n) reindex — loop becomes O(n²)
}// O(n) — append then reverse once:
$result = [];
foreach ($items as $item) {
$result[] = $item; // O(1) append
}
$result = array_reverse($result); // O(n) once at end
// Or use SplStack / SplDoublyLinkedList for O(1) prepend:
$stack = new SplStack();
foreach ($items as $item) $stack->push($item);