Compare · xerj
Webfold vs xerj
Webfold's folder search put the right file first more often than xerj. That held in every category we split out. It is merged to the main branch, in no release yet. xerj's running node was faster in one cold-start cell (4.5 against 10.7 ms). This compares file search only.
xerj is a Rust search engine with an Elasticsearch-compatible API. Searching files on disk is the one job it shares with Webfold. Both indexed the same two folders (554 files, 1,026 files). One query set was held out. Webfold is the folder search in its main branch, in no release yet.
Webfold on its own
How fast is Webfold alone?
Each job is measured on its own. The performance page states the figures once. We link them here.
- Parse search results and search a folder: 1.4 ms a results page. 49.3 MB a second parsing; 0.42 s to index 554 files.
Now the comparison
Webfold against xerj
| Aspect | Webfold | xerj |
|---|---|---|
| Right file ranked first (hit@1), Webfold's files, 240 queries | 0.946 | 0.808 |
| hit@1 on held-out queries (188) | 0.931 | 0.739 |
| hit@1 on a second folder (1,026 files, 240 queries) | 0.846 | 0.683 |
| Right file in the top five (hit@5), Webfold's files | 1.000 | 0.950 |
| Mean reciprocal rank, Webfold's files | 0.971 | 0.875 |
| Keyword queries on code, hit@1 | 0.917 | 0.617 |
| Phrase queries on prose, hit@1 (own files / held-out / second folder) | 1.000 / 0.917 / 0.867 | 0.983 / 0.817 / 0.717 |
| Index build | 0.42 s | 46.6 s (8.7 s of CPU) |
| Per query, a new process each time (median) | 4.0 ms | 162 ms on the second folder, 2.2 s on the first (search command) |
| Per query, long-lived process (median) | 0.7 ms (serve) | 3.4 ms (node) |
| Memory of the long-lived process | 16 MB (serve); 20 MB peak for a one-shot query | 468 to 516 MB (node; 997 MB peak while indexing) |
| Index on disk | 4.8 MB | 28.4 MB |
| Cold start with files evicted | 10.7 ms (a process); serve first query 2.6 ms | 4.5 ms (running node) |
Where is each tool ahead?
Where xerj is ahead
- A cold start on Webfold's own files. xerj's running node answered in 4.5 ms with its data files evicted. A Webfold process took 10.7 ms. The two are not the same measurement. A cold Webfold serve answered in 2.6 ms.
- A long-lived service with an Elasticsearch-compatible API. It has an MCP server. It has neural modes. It has hybrid modes. We tested none of them.
Where Webfold is ahead
- Finds the right file first more often in every category we split out. That holds on both folders. It holds on held-out queries. It includes phrases on prose. xerj won those in our first run.
- Indexes about 100 times faster. Keeps a 4.8 MB index against 28.4 MB.
- No server to run. A query in a fresh process takes about 4 ms. It uses 20 MB. An optional serve mode answers in under a millisecond. It uses 16 MB.
How do I move from xerj to Webfold?
| If you use | In Webfold |
|---|---|
| xerj autoindex + search | webfold folder-search <dir> "query" |
What is the evidence?
Each figure states its dataset. It states its limits.
FAQ
Frequently asked questions
Is this only a test on your own files?
Mostly: two folders (ours and the superdocuments repository's text files), lexical ranking only, and queries cut from the folders, which favours exact-match engines. A held-out query set built a different way gave the same ordering, but it samples the same files. We did not test xerj's neural or hybrid modes.
Why do the results differ from your 4 November run?
That run found two Webfold defects: it parsed a JSON index on every call and ignored word order, so xerj won phrases on prose (0.917 against 0.783) and per-query time. The folder search was changed, the before and after were measured on the same files, and the before still shows the old gap (prose phrases 0.733). The folder is also not the same 483 files, which could not be reproduced.
Why is xerj's search command so much slower on the first folder?
We measured about 0.9 s of CPU in the xerj client on that folder and 26 ms on the second, and could not find why; the 4 November run saw 127 ms. Treat the second folder's 162 ms as the fairer figure for that command, and the node's 3 to 6 ms for the node.
Try it on your own pages.
Run the command-line tool. Join the waitlist for the hosted API.