---
title: 'jXBW: Extended BW for JSONL Search'
url: https://www.emergentmind.com/topics/jxbw
type: topic
---

# jXBW: Extended BW for JSONL Search

jXBW, expanded as JSONL eXtended Burrows–Wheeler Transform, is a method for fast substructure search over large-scale JSON Lines (JSONL) datasets. It targets a setting in which each JSONL line is treated as a structured object and queries are specified as subtree patterns rather than flat text predicates. The method combines three components: a merged-tree representation of many JSON objects, a succinct index derived from the eXtended Burrows–Wheeler Transform (XBWT), and a three-step search procedure based on path decomposition, ancestor computation, and adaptive tree-identifier collection. Reported experiments on real-world datasets show substantial speedups over tree-based and XML-based baselines while maintaining competitive memory usage [2508.12536].

## 1. Problem setting and scope

Substructure search in JSONL datasets is described as essential for modern applications such as prompt engineering in foundation models, yet existing methods are characterized as computationally expensive because they rely on exhaustive tree traversal and subtree matching [2508.12536]. In this setting, each JSON object must be parsed into a tree, and a query asks whether some subtree pattern occurs within one or more of those trees.

The operational target of jXBW is not generic document retrieval but substructure retrieval over large JSONL corpora. The paper situates this need in workflows where JSONL acts as the de facto format for Foundation Model inputs, including GPT, Claude, and LLaMA. Fast retrieval of structured fragments is therefore connected to on-the-fly selection of context for database-style prompts and retrieval-augmented generation. A plausible implication is that jXBW addresses a bottleneck that emerges when structured corpora are queried repeatedly in latency-sensitive inference pipelines [2508.12536].

A common misconception in this area is that JSONL substructure search can be reduced straightforwardly to XML tooling. The reported comparison against a JSON→XML + XQuery baseline indicates that such a reduction can incur severe performance penalties, especially at larger scales. Another misconception is that speedups in this domain must come from approximate or weakened matching; jXBW is instead framed as a correctness-preserving method that avoids exhaustive traversal through indexing and search decomposition [2508.12536].

## 2. Merged-tree data model

Each JSONL line \(O_i\) is parsed into a rooted, labeled tree \(T_i\). Objects become unordered children under an “object” node, arrays become ordered children, and every leaf of \(T_i\) is tagged with its source ID \(i\) [2508.12536]. This object/array distinction is central because it determines where ordering constraints must later be enforced during matching.

The individual trees \(\{T_i\}_{i=1}^N\) are merged into a single tree \(MT\) by identifying common root-to-node label sequences, described as prefix paths. If two trees share the same label at a given position, those nodes are fused; otherwise, the divergent subtree is attached under the last common prefix. This merged-tree construction preserves per-object identity at the leaves: each leaf \(\ell\) of \(MT\) carries a set
\[
ids(\ell)\subseteq\{1,\dots,N\}
\]
containing all original trees contributing to that path [2508.12536].

The resulting structure is explicitly bounded by
\[
|MT|\le \sum_i |T_i|,
\]
with the additional observation that in practice \( |MT| \ll \sum_i |T_i| \) when structure is widely shared. This means that repeated schemas or repeated nested patterns across a corpus are collapsed into shared prefixes rather than stored redundantly. The method therefore uses structural commonality as an indexing primitive rather than merely as a compression side effect.

Construction cost is analyzed in two variants. A naïve sequential merge would require
\[
O\!\left(\sum_i |T_i| \times N\right).
\]
By instead performing pairwise merges in a balanced divide-and-conquer schedule over \(\log N\) rounds, the total merge time becomes
\[
O\!\left(M_{\mathrm{tot}}\log N\right),
\qquad
M_{\mathrm{tot}}=\sum_{i=1}^N |T_i|.
\]
This suggests that jXBW’s scalability depends not only on succinct indexing but also on avoiding pathological merge orderings during preprocessing [2508.12536].

## 3. XBWT-based succinct index

The merged tree \(MT\) is converted into a compact index, also called jXBW, composed of four synchronized arrays of length \(n=|MT|\). These are \(A_{\mathrm{label}}[1..n]\), which stores a symbol for each node via a bijection from string labels to an alphabet \(\Sigma\) with \(|\Sigma|=\sigma\); \(A_{\mathrm{last}}[1..n]\in\{0,1\}\), which marks whether a node is the rightmost child of its parent; \(A_{\mathrm{leaf}}[1..n]\in\{0,1\}\), which marks leaves; and \(A_{\mathrm{ids}}\), a compacted list of leaf-ID sets indexed by \(\mathrm{rank}_1(A_{\mathrm{leaf}},i)\) [2508.12536].

Construction proceeds in four stated steps. First, a DFS is run on \(MT\) with children sorted lexicographically. Second, the arrays \(A_{\mathrm{label}}\), \(A_{\mathrm{last}}\), \(A_{\mathrm{leaf}}\), and \(A_{\mathrm{ids}}\) are recorded. Third, the sequence is stably sorted by the ancestor-string key \(A_{\mathrm{anc}}\), which is used only during build. Fourth, a wavelet matrix is built on \(A_{\mathrm{label}}\) for rank/select over \(\sigma\), and rank/select dictionaries are built on the bitvectors [2508.12536].

The stated space complexity is
\[
O(n\log \sigma)\ \text{bits}
\]
plus low-order overhead. The emphasis on wavelet matrices and rank/select dictionaries shows that the index is designed for navigation and search rather than passive storage. It is therefore not merely a succinct encoding of the merged tree; it is a searchable representation whose primitives are directly exposed.

The key operations include `Children(i)`, `RankedChild(i,k)`, `CharRankedChild(i,c,k)`, `Parent(i)`, `TreeIDs(i)`, and `SubPathSearch(P)`. Except where noted, these operations run in \(O(\log \sigma)\) time, while `TreeIDs(i)` for leaves is \(O(1)\) via rank on \(A_{\mathrm{leaf}}\) [2508.12536]. `SubPathSearch(P)` is especially significant: for a path
\[
P=\langle p_1,\dots,p_k\rangle,
\]
it returns a contiguous range \([f,l]\) of all positions reachable by \(P\) from any root. The method uses a small “first-occur” array \(F(c)\) to locate the region where nodes whose parent label is \(c\) begin, then refines the interval by rank/select steps over \(A_{\mathrm{label}}\). A plausible implication is that the contiguous-range property is what allows the later search algorithm to aggregate path matches without scanning the entire structure.

## 4. Three-step search procedure

For a query tree \(Q\) with \(p\) root-to-leaf paths \(P_1,\dots,P_p\), jXBW decomposes substructure search into three stages: path decomposition and matching, ancestor computation, and adaptive tree-ID collection [2508.12536].

In the first stage, all root-to-leaf label sequences of \(Q\) are extracted:
\[
\{P_j=(q_{j,1},\dots,q_{j,k_j})\}_{j=1}^p.
\]
For each \(P_j\), the algorithm calls
\[
[f_j,\ell_j]\leftarrow \mathrm{SubPathSearch}(P_j),
\]
which costs \(O(|P_j|\log \sigma)\), and gathers the resulting ranges \(R_j\). This converts a subtree query into a set of indexed path queries over the merged tree [2508.12536].

In the second stage, each matching leaf position \(i\in[f_j,\ell_j]\) is treated as an occurrence of path \(P_j\), and the algorithm ascends exactly \(|P_j|-1\) times using `Parent`. The computed set
\[
\mathrm{CompAncestors}([f_j,\ell_j],P_j)
=
\left\{
\underbrace{\mathrm{Parent}\circ\cdots\circ\mathrm{Parent}}_{|P_j|-1}(i)\mid i\in[f_j,\ell_j]
\right\}
\]
produces ancestor positions \(A_j\) for each path. Their intersection
\[
R:=\bigcap_{j=1}^p A_j
\]
defines candidate subtree-root positions containing all query paths. This stage is the mechanism by which independent path hits are reassembled into candidate subtree matches [2508.12536].

The third stage adapts to JSON structure. For each root candidate \(r\in R\), if \(Q\) contains JSON arrays, the method invokes `StructMatch(r,Q)`, which enforces ordering via repeated `CharRankedChild` calls and yields sets of leaf IDs. Otherwise, it invokes `CollectPathMatchingIDs(r,\{P_j\})`: from each \(P_j\), the algorithm walks down from \(r\) using `CharRankedChild`, collects leaf positions, unions their `TreeIDs`, and then intersects the \(p\) ID sets for that root. The final answer is obtained by taking the union over all candidate roots [2508.12536].

This design clarifies the role of arrays. Ordering is not globally imposed on all matching, because objects are represented as unordered children while arrays are represented as ordered children. The adaptive branch therefore prevents unnecessary structural checking when the query does not require ordered semantics, while still preserving correctness for array-containing patterns.

## 5. Complexity profile

The preprocessing costs are separated into merged-tree construction and jXBW construction. The merged-tree build takes \(O(M_{\mathrm{tot}}\log N)\) time and \(O(|MT|)\) space. jXBW construction then takes \(O(|MT|\log \sigma)\) time and space, reflecting the cost of the wavelet matrix and bitvectors [2508.12536].

For substructure search, the analysis uses the following parameters: \(p\), the number of query paths; \(d\), the average path length; \(r=\sum_j |\text{range }R_j|\), the total number of leaf hits; \(c=|R|\), the candidate root count; and \(b\), the average branching factor for structural match. The stated time bound is
\[
O\bigl(p\,d\,\log \sigma\bigr)
+
O\bigl(r\,d\,\log \sigma\bigr)
+
O\bigl(c\,(|Q|\,b)\,\log \sigma\bigr),
\]
equivalently
\[
O\bigl((p+r)d\log \sigma + c\,|Q|\,b\,\log \sigma\bigr).
\]
The contrast baseline is a naive tree scan on \(MT\), which costs
\[
O(|MT|\times |Q|).
\]
This establishes that jXBW’s asymptotic advantage comes from restricting work to path-hit intervals, ancestor backtracking, and candidate-root refinement rather than scanning all nodes against all query structure [2508.12536].

The complexity expression also makes explicit that search cost is shaped by query decomposition and data-dependent hit counts. This suggests that performance will depend not only on corpus size but on how selective the decomposed paths are and on how many candidate roots survive the ancestor intersection step.

## 6. Empirical evaluation and reported use cases

The evaluation uses seven real-world JSONL datasets ranging from 36 K to 6.6 M objects, with depths 2–6 and with some datasets containing 0–100% arrays. The reported baselines are Ptree, a pointer-based merged tree; SucTree, a LOUDS-based succinct tree; and Saxon, a JSON→XML + XQuery pipeline [2508.12536].

Two datasets are summarized numerically in the provided results. On **movies** with 36 K objects, average query time is reported as 0.016 ms/query for jXBW, compared with 0.265 for Ptree, 2.05 for SucTree, and 3.96 for Saxon. On **pubchem** with 1 M objects, average query time is 0.043 for jXBW, compared with 26.45 for Ptree and 205.19 for SucTree; Saxon did not finish in 24 h, corresponding to a reported gap of more than \(6\times 10^6\) [2508.12536]. These figures instantiate the broader summary claim that jXBW achieves speedups of \(16\times\) for smaller datasets and up to \(4{,}700\times\) for larger datasets over tree-based approaches, while exceeding XML-based processing by more than \(6\times 10^6\).

| Dataset | Average query time (ms/query) | Memory usage (MB) |
|---|---:|---:|
| movies (36 K objs) | jXBW 0.016; Ptree 0.265; SucTree 2.05; Saxon 3.96 | jXBW 56; Ptree 66; SucTree 50; Saxon 329 |
| pubchem (1 M objs) | jXBW 0.043; Ptree 26.45; SucTree 205.19; Saxon \(>24\) h | jXBW 3 880; Ptree 4 702; SucTree 3 453; Saxon 64 840 |

The reported memory figures indicate competitive usage rather than universal minimization. On movies, jXBW uses 56 MB, compared with 66 for Ptree, 50 for SucTree, and 329 for Saxon. On pubchem, jXBW uses 3 880 MB, compared with 4 702 for Ptree, 3 453 for SucTree, and 64 840 for Saxon [2508.12536]. This suggests that the method’s primary contribution is latency reduction with memory remaining in the same broad regime as succinct tree alternatives, rather than uncompromising minimization of footprint.

Index construction time is described as dominated by tree merging, consistent with the \(O(M_{\mathrm{tot}}\log N)\) bound. The paper further states that jXBW’s build is comparable to Ptree and SucTree and within a constant factor of Saxon’s XML pipeline [2508.12536]. This matters because the reported speedups are not attributed to an unrealistic preprocessing budget.

The application discussion connects jXBW to prompt engineering and structured RAG, where JSON-native retrieval can return only the JSON documents containing a given subtree pattern in sub-millisecond time. A concrete scientific case study is given for PubChem: querying for \(N^+\)-containing substructures took 21 ms with jXBW, versus 145 ms for Ptree and 335 ms for SucTree, and the resulting compounds were immediately fed into GPT-4 for downstream analysis, described as a symbolic–neural workflow [2508.12536]. Proposed extensions include approximate matching by edit distance, support for other semi-structured formats such as Avro and Protobuf, and distributed jXBW for corpora larger than 100 GB. These extensions are not reported as completed features; they are forward-looking directions that indicate where the method could be generalized.

Source: https://www.emergentmind.com/topics/jxbw