Devotd Github
NewRAG & retrieval

graphersal/graphersal — Gremlin Evaluator Stack Frame Reduction

The latest commit in graphersal/graphersal separated the GQL evaluator's recursive frames, which had grown larger because of regex links, into standalone functions to prevent a stack overflow in debug builds.

Repositorygraphersal/graphersal ↗

The latest commit in graphersal/graphersal separated the GQL evaluator's recursive frames, which had grown larger because of regex links, into standalone functions to prevent a stack overflow in debug builds.

GitHub description: In-memory graph database and Gremlin traversal engine in Rust: browser playground, CLI, MCP server for AI agents, durable store, Python bindings.

stars
★ 15
Forks
0
Language
Rust
License
Apache-2.0
Latest release
v0.1.1
Read original source ↗View on GitHub ↗

graphersal/graphersal is an in-memory graph database and Gremlin traversal engine written in Rust. It bundles a browser playground and CLI, an MCP server for AI agents, and Python bindings. The commit 9de2d54 of November 3, 2026 fixed a stack usage problem in the GQL evaluator. The source is https://github.com/graphersal/graphersal/commit/9de2d54.

The `=~` regex matching link added one branch each to compile_chain and eval_chain, which descend recursively, and in unoptimized builds each branch leaves a stack slot for a temporary value. As a result the stack grew by roughly 540 bytes per nesting level, so the deep_expressions_evaluate_without_overflow test, which checks deeply nested expressions, exceeded the thread stack set to 512 KiB in the Windows CI debug build and a stack overflow occurred.

The commit separated rarely used links (`=~`, `IS LABELED`, `IS SOURCE / DESTINATION OF`, slices) into compile_rare_link and rare_link, so that each is compiled and evaluated in its own independent frame. According to the macOS debug measurements stated in the commit message, the stack usage of that test is 450 KiB. Before adding `=~` it was 452 KiB, and when `=~` was added it was 484 KiB; the nested subscript case was 386 KiB, and before the fix it was 401 KiB.

However, these figures are measurements from a single macOS debug environment, and it is not recorded whether the same symptom appears in optimized builds. The change is 79 lines in one file, crates/graphersal/src/gql/eval.rs (56 lines added, 23 lines deleted), and the query semantics of GQL are unchanged, so there is no functional change visible to users. In other words, the only published evidence is the stack usage in debug builds, so it is too early to judge the impact on release build performance.