AmazonScience/SpIDER-Bench

SpIDER-Bench

Repository dependency graphs for software issue localization — the graph data behind SpIDER: Spatially Informed Dense Embedding Retrieval for Software Issue Localization (arXiv:2512.16956).

Each benchmark instance gets one directed multigraph of its repository at the commit the issue was filed against. Nodes are directories, files, classes and functions carrying their source; edges are contains / imports / inherits / invokes relations between them. SpIDER uses these graphs to expand a dense-retrieval ranking along the code's own structure.

3,297 graphs · 44,877,941 nodes · 671,599,117 edges across three benchmarks and four languages.

Configurations

Three configs: `instances` (default, one row per graph), `nodes` and `edges`. nodes and edges each carry the same eight splits, one per benchmark+language:

nodes and edges are separate configs rather than two splits of one, because datasets casts every split in a config to a single schema and node rows and edge rows have different columns.

Loading

from datasets import load_dataset

# the summary table: one row per instance
inst = load_dataset("AmazonScience/SpIDER-Bench", "instances", split="train")

# the graph tables for one benchmark+language
nodes = load_dataset("AmazonScience/SpIDER-Bench", "nodes", split="swe_polybench_python")
edges = load_dataset("AmazonScience/SpIDER-Bench", "edges", split="swe_polybench_python")

Graphs are stored relationally rather than one-row-per-graph because a single instance reaches hundreds of MB — too large for a parquet row or the viewer.

Rebuilding the graphs

The reference implementation consumes networkx.MultiDiGraph pickles. The SpIDER code release ships scripts/materialize_graphs.py, which rebuilds them and downloads only the shards it needs:

python scripts/materialize_graphs.py --out data/SpIDER-Bench
python scripts/materialize_graphs.py --out data/SpIDER-Bench --subset SWE-PolyBench/python

To rebuild one graph directly:

import json, networkx as nx, pyarrow.parquet as pq

NODE_COLS = ["type", "code", "start_line", "end_line", "package", "imports",
             "method_name", "class_name", "parent_type", "is_prototype_method"]
EDGE_COLS = ["type", "alias", "module"]

def rebuild(node_rows, edge_rows):
    g = nx.MultiDiGraph()
    for r in sorted(node_rows, key=lambda r: r["node_ord"]):
        g.add_node(r["node_id"], **attrs(r, NODE_COLS))
    for r in sorted(edge_rows, key=lambda r: r["edge_ord"]):
        g.add_edge(r["src"], r["dst"], key=r["edge_key"], **attrs(r, EDGE_COLS))
    return g

def attrs(row, cols):
    if not row["attr_order"]:
        return {}
    extra = json.loads(row["extra_attrs"]) if row["extra_attrs"] else {}
    return {k: extra[k] if k in extra else row[k] for k in row["attr_order"].split(",")}

Schema

instances

nodes

edges

Why attr_order and *_ord

Attribute sets differ by language and, within a language, between node kinds — a java node carries package, a directory node carries only type. Parquet null cannot distinguish attribute absent from attribute present with value `None`, and both occur here. So attr_order records exactly which keys the original dict held and in what order, and it is what a faithful rebuild iterates. node_ord / edge_ord preserve networkx insertion order, which SpIDER's BFS tie-breaks depend on.

Round-tripping every graph in this release through networkx.utils.graphs_equal against the original pickles passes for all 3,297, including node order, edge order and per-node attribute key order.

Citation

@misc{chaudhari2026spiderspatiallyinformeddense,
      title={SpIDER: Spatially Informed Dense Embedding Retrieval for Software Issue Localization}, 
      author={Shravan Chaudhari and Rahul Thomas Jacob and Mononito Goswami and Jiajun Cao and Shihab Rashid and Christian Bock},
      year={2026},
      eprint={2512.16956},
      archivePrefix={arXiv},
      primaryClass={cs.SE},
      url={https://arxiv.org/abs/2512.16956}, 
}

License

See LICENSE and notice.md. This repository contains code segments under multiple licenses (MIT, Apache 2.0, BSD, GPL and others) and is adapted from the listed open-source projects; your use must comply with the relevant segments' licenses.