Benchmark
The Benchmark section of F8 Studio measures one thing: how fast Fallen-8 traverses edges in memory. It follows every outgoing edge of every vertex in the currently loaded graph, regardless of edge type (edge type vs label), and reports edges traversed per second (TPS). This is raw traversal throughput, not query latency and not analytics timing.
The screen (route /benchmarks) is Fallen-8-level: rather than taking a namespace parameter, it
always generates into and measures the default namespace’s graph on the active instance,
whatever namespace the switcher is on. It does not aggregate across namespaces.
Running a benchmark
Section titled “Running a benchmark”- Open Benchmark in the left rail.
- (Optional) Give it a graph to measure. You can point the benchmark at anything already
loaded, a sample, a restored save game,
or your own data, so this step is only needed when the graph is empty. To conjure one, use the
Graph generation panel: set
vertices,edges / vertex, and adistribution, or click a preset, then Generate. - Set iterations (default 1000) in the Edge-traversal throughput panel and click Run benchmark.
Results appear as edges per run, average TPS, median TPS, and standard-deviation TPS, plus a per-session run history table (in memory, not persisted) so you can compare runs as you change the graph or the iteration count. More iterations tighten the median and standard deviation.
What the numbers mean
Section titled “What the numbers mean”- edges per run equals the total edge count of the loaded graph (the sum of out-degrees). Each iteration follows every out-edge exactly once, dereferencing each edge’s target vertex so the pass does real pointer-following work, not a cached-degree read.
- average / median / stddev TPS are computed over the per-iteration throughput samples. TPS is traversed edges per second.
The traversal is schema-agnostic: it walks every out-edge group of every vertex whatever the edge type, and never looks at labels, so the number is comparable across generated graphs, samples, and your own data.
Graph generation
Section titled “Graph generation”The generation panel is a convenience for producing a graph to measure. A few things to know:
- It is additive. Generated vertices and edges are added on top of the current graph; nothing is wiped. Generated edges only ever target vertices from the same call, so generating on top of a loaded sample leaves a second, disconnected component: generate into an empty graph when the numbers (or the analytics) should describe one dataset.
edges / vertexis per vertex, so the total edge count is roughlyvertices x edges/vertex. Targets are drawn distinct, so the out-degree is silently capped at the number of generated vertices (nodeCount=200&edgeCount=500yields 40,000 edges, not 100,000), and underpreferentialthe earliest vertices get fewer by construction.- Presets: small (200 vertices, 5 edges each,
uniform), medium (10,000 x 10,uniform), and scale (100,000 x 10,preferential, roughly one million edges). A preset sets the distribution too, not just the counts. The scale preset is heavy: expect seconds of server work and real memory use. - distribution:
uniformspreads edges evenly (no hubs);preferentialuses Barabasi-Albert-style attachment, so heavy-tailed hubs emerge and analytics such as PageRank show real structure at scale.
Generated vertices and edges carry no label at all; the generated edges’ type (edgePropertyId) is
A. That type is a generation detail only, and the benchmark traverses every edge whatever its
type, but it is the value to query a generated graph by, as in GET /vertex/{id}/edges/out/A.
Performance notes
Section titled “Performance notes”The benchmark is a CPU-parallel, in-memory traversal (a partitioned parallel scan sized to the processor count). Throughput scales with CPU cores and memory bandwidth. There is no GPU code path here: GPU acceleration in Fallen-8 reaches only the model sidecars (Ollama and the NLP enrichment tier), never graph traversal.
One call does iterations x edges traversals inside a single synchronous request, using every
core: at the scale preset’s roughly one million edges, the default 1,000 iterations is about a
billion edge dereferences. iterations is capped server-side by
Fallen8:Security:BenchmarkMaxIterations (default 10000); a higher count is a 400, and an omitted
one uses 1,000 clamped to the ceiling. A pass still cannot be cancelled once it has started, so lower
the count (10 to 50) on million-edge graphs and do not benchmark an instance that is serving traffic.
REST equivalents
Section titled “REST equivalents”The screen calls two Fallen-8-level endpoints. Both are exposed at the API root as bare paths
(not under the versioned api/v0.1 prefix) and operate on the default namespace:
| Method and route | Purpose |
|---|---|
GET /generate?nodeCount=&edgeCount=&distribution= |
Add a generated graph (returns a human-readable timing summary). |
GET /benchmark?iterations= |
Run the timed edge-traversal passes (returns the TPS statistics). |
All three /generate parameters are optional, with server-side defaults of 200 vertices, 5
out-edges per vertex, and uniform. A non-numeric or negative count, or a distribution other than
uniform or preferential, answers 400.
GET /benchmark returns iterations, edgesTraversed (edges in a single pass), averageTps,
medianTps, and standardDeviationTps. iterations also defaults to 1000 when omitted. It
answers 400 on a graph with no vertices, and on a non-numeric or non-positive iteration count.
See the full contract in the API reference.
See also
Section titled “See also”- F8 Studio is the workbench this screen lives in.
- Running Fallen-8 covers launch options and configuration that affect performance.
- Architecture shows how the engine and REST API fit together.