Introduction

When developers ask which algorithm usort() uses internally, they are usually trying to answer one of two practical questions: how fast will this be, and can I rely on stable ordering for equal items. The most important answer is that PHP's public contract for usort() is about the comparison callback, not about exposing a guaranteed sort algorithm. Internal implementation details can change between versions, so production code should depend on the function's documented behavior rather than a specific named algorithm.

What usort() Guarantees

usort() sorts an array in place using a user-provided comparison function. The comparison callback must return:

• a value less than zero when the first item should come first
• zero when the items compare equal
• a value greater than zero when the first item should come after the second

A basic example looks like this:

1<?php
2$users = [
3    ["name" => "Ana", "age" => 31],
4    ["name" => "Ben", "age" => 24],
5    ["name" => "Cara", "age" => 28],
6];
7
8usort($users, function ($a, $b) {
9    return $a["age"] <=> $b["age"];
10});
11
12print_r($users);

That is the interface you should code against. The exact internal algorithm is intentionally treated as an implementation detail.

Why the Exact Algorithm Is the Wrong Dependency

Historically, PHP's internal sort routines have been quicksort-derived or hybrid engine implementations rather than a user-visible promise such as "this function is always mergesort." Engine maintainers are free to change internals for performance or stability reasons.

That means two things for application code:

• do not write logic that depends on a specific pivot strategy or recursion shape
• do not treat old version-specific implementation notes as part of the long-term API contract

If you care about big-O behavior, the practical expectation is comparison-sort behavior, which is generally around O(n log n) average time. If your comparator is expensive, the callback cost can dominate the runtime more than the internal algorithm choice.

Stability Matters More Than the Name

In everyday code, stability is usually a more relevant question than whether the engine is using quicksort, timsort, or something hybrid.

A stable sort preserves the original relative order of elements that compare equal. That matters when you sort by one key after already arranging by another key.

1<?php
2$rows = [
3    ["group" => "A", "id" => 1],
4    ["group" => "A", "id" => 2],
5    ["group" => "B", "id" => 3],
6];
7
8usort($rows, function ($left, $right) {
9    return $left["group"] <=> $right["group"];
10});
11
12print_r($rows);

If equal group values preserve input order, the output is easier to reason about. In modern PHP, equal elements behave more predictably than they did in older versions, but it is still best to write explicit comparison logic for the ordering you actually need.

Writing Better Comparators

Most usort() problems come from bad comparators, not from the internal engine algorithm.

Good comparator rules:

• return consistent results
• compare the same fields in the same order every time
• avoid boolean returns such as true and false
• use the spaceship operator when possible

A multi-key comparator is often clearer than trying to depend on sort stability implicitly:

1<?php
2usort($rows, function ($left, $right) {
3    return [$left["group"], $left["id"]] <=> [$right["group"], $right["id"]];
4});

This removes ambiguity and makes your intended ordering explicit.

Performance Expectations

For typical use, usort() is fine for in-memory application data. The main cost drivers are:

• array size
• complexity of the comparison callback
• whether the callback does expensive work such as string parsing or database lookups

If performance is critical, optimize the comparator first. Precompute values instead of recalculating them on every comparison.

Common Pitfalls

• Relying on an unofficial claim that usort() always uses one specific named algorithm.
• Returning booleans from the comparator instead of negative, zero, or positive values.
• Assuming stability without checking the PHP version and the documented behavior you care about.
• Doing expensive computation inside the comparison callback.
• Using usort() when a key-preserving function such as uasort() would better match the data structure.

Summary

• PHP's usort() does not expose a specific sort algorithm as part of its public contract.
• The safe assumption is comparison-sort behavior, not a guaranteed named implementation.
• In practice, comparator correctness matters more than the engine's internal sort details.
• If ordering rules matter, encode them directly in the callback instead of depending on side effects of stability.
• For most real code, understand the API contract and comparator semantics, not just the algorithm label.