phpantom_lsp indexes a Laravel codebase in two seconds and marks itself unavailable on Symfony

The headline timing row compares a server with no cache against four that have one

The performance table has five rows and the first is the one the description would lead you to read. Time to ready from cache reads two seconds for this project, against eleven seconds for one competitor, ten for another, three minutes for a third, and just over a minute for the commercial IDE. Two of those competitor figures carry a number in parentheses, which is the warm cache time, and the disk cache row shows why: this project has a dash there, meaning it keeps none, while the others range from fifty megabytes to two and a half gigabytes. So the comparison puts a cold start next to results that can be warm. The rows underneath are fairer. Resident memory sits mid-pack at just over half a gigabyte, and CPU time is second best at seventeen seconds, one second behind the fastest.

The benchmark codebase is the framework this server supports best

The measurement note is specific: a production Laravel codebase with five thousand PHP files, thirteen hundred Blade templates, and twenty seven thousand vendor files, nearly two million lines in total. In the framework rows, this project is marked as supporting Laravel and Blade, unavailable for Symfony and Twig, partial for Drupal, and partial for everything else. Two competitors score better on that Symfony row, one partially and one through a plugin. So the strongest evidence in the table comes from the framework the project is built around, and a shop running Symfony has to discount the whole comparison. The page is straightforward about the gaps, which is worth crediting; the ordering of the evidence is the part to keep in mind.

One row is a genuine architectural difference: analyzer errors become quick fixes

Most rows in the table are capability checkmarks that different projects would draw differently. One row carries a footnote that explains a real mechanism. This server runs three external analyzers inside itself, and it converts their reports into editor quick fixes. The alternatives bundle or proxy analyzers as well, but, as the footnote says, both only relay the errors. That is the difference between surfacing a diagnostic and offering a fix at the cursor, and it is why that row is the only one where two competitor columns are marked unavailable or partial. The rest of the footnotes are ordinary capability definitions, listing what counts as core protocol features, what counts as advanced navigation, and what counts under editor extras.

The verification path ships inside the repository

A comparison this dense is usually a slide, and slides are not falsifiable. This one is not. The page tells you to open the bundled example directory in your editor and trigger completion at the marked locations in one file, and says it exercises every type inference feature in the table including the cases where the tools disagree. A second example is a standalone Laravel project with real models, configuration, routes, views, and translations, covering Eloquent property resolution, query builder chaining, scopes, custom collections, and navigation to config keys, route names, and translation strings. There is also a third check outside the project: an independently hosted conformance suite covering twelve engines, which includes the commercial tools' engines, so the comparison is not graded only by the party publishing it.

Nine pinned crates lock the analysis core to a single patch release

The dependency list is where the maintenance cost shows. Nine crates from one project, covering syntax, allocation, a database layer, names, doc comment syntax, spans, a formatter, a PHP version table, and a Composer manifest parser, are all pinned with an equality requirement to the same patch version. So the entire analysis core moves as a block, and an upgrade touches nine lines rather than one. Two other dependencies are worth noting because they explain features rather than infrastructure: a formatter crate, which is why formatting appears among the editor extras, and a SQL parser, which is presumably there to read embedded queries. The async runtime is declared per target, with the full feature set on native builds and a slim one for WebAssembly, because the wasm target has no sockets and the networking feature would pull in a dependency that fails to compile there.

The allocator is pinned for Linux so a local build behaves like the shipped one

There is a comment in the build file about memory allocation that is more specific than most projects manage. The allocator shipped for Linux builds is chosen because musl's built in one is very slow under the workload this server creates, which is many threads parsing and indexing in parallel, and the stated penalty is four to six times slower whole project analysis. The interesting decision is the scope: the setting is applied to Linux rather than to the C library alone, so a developer building on a workstation with the other C library gets the same allocator as the released binary. The reason given is that every Linux artifact published is static musl, so narrowing the rule to musl would leave local builds measuring something different from what users download. That is a small, careful piece of engineering with a comment explaining the trade in full.

Four ecosystems of build and documentation config sit in one root

The root inventory explains the table's claims about verification. There is the Rust crate manifest and lock file, plus a cross compilation config for the binary targets, a Nix flake with its own lock, a build script, a bench directory, and a shell script that drives the server in a test. On top of that sits a Python project for the documentation site, whose declared dependency list is empty and whose tools live in a development group instead, together with a lock file for that manager and a config file for the site generator. There is a lock file for type stubs, which is what a language server uses to describe library APIs it does not read, a JSON schema for the editor configuration, an editor config directory for one specific editor, and two assistant instruction files. The project runs four package managers to build itself and its docs, which is more than the language server needs.

Editorial conclusion

Try it if you write PHP on Laravel and your editor's language support is the bottleneck, since indexing runs in the background and the verification projects in the repository let you check the claims without reading the table. Do not expect it to help on Symfony, where the project lists itself as unavailable, or on other frameworks it marks as partial. Before you switch, note that the timing comparison leans on the fact that this server keeps no disk cache at all, so the two second cold figure has no warm counterpart, and check the memory and CPU rows instead, which are the ones that can be compared directly.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes