perf: cache component parse/compile

[jordanrfrazier]

perf(components): cache component parse/compile output instead of re-parsing per vertex

The problem

eval_custom_component_code parsed the source twice with ast.parse, compiled
it, and exec'd it — once per vertex, on every flow build. The source is a
constant: for a shipped component it is byte-identical on every request, forever.

Independent profiling puts this at 57–86% of all Graph.from_payload time,
measured across six real flows.

The fix

Cache the immutable output — the class name and two code objects — and exec a
fresh class from it on each call.

Why not just cache the class?

That was tried, and reverted: it is a cross-tenant data leak.

Two tenants with byte-identical source would share one class object, and with it
any class-level mutable state — the classic _seen = [] mistake, which matters
because Langflow targets non-expert Python users. It does not even take two
tenants: sibling vertices in one graph layer build concurrently via
asyncio.gather.

exec()-ing a class statement's code object always produces a new class, so
caching the code object is safe where caching the class is not. exec_globals
is rebuilt per call for the same reason.

Measured

Graph.from_payload on real starter flows:

flow	nodes	before	after	change
Vector Store RAG	7	45.44 ms	7.42 ms	−83.7%
Hybrid Search RAG	11	54.34 ms	13.19 ms	−75.7%
Document Q&A	7	42.52 ms	7.68 ms	−81.9%
Simple Agent	6	33.41 ms	6.79 ms	−79.7%
Basic Prompting	6	9.49 ms	3.37 ms	−64.5%

Per component, over 23 real components: median 1.589 ms → 0.100 ms.

The win is largest where components are heavy (Knowledge 12.99 → 0.658 ms, File
9.32 → 0.397 ms) — which is why a small synthetic flow badly understates it. A
2-node benchmark shows only −14% CPU.

What is left, and why it stays

The residual ~0.1 ms per component is the fresh exec. That is the price of the
isolation, and it is not worth chasing: import resolution accounts for only
0.038–0.063 ms of it, so there is no meaningful further win without sharing
state between instances.

Why the Guardrails fix ships with this

It is not incidental. The cache is only safe if no shipped component writes to
module-level state, and test_no_shipped_component_writes_to_module_level_state
fails without the fix. component_index.json carries that component's
regenerated code_hash.

Verification

209 tests pass.

Mutation-verified: reintroducing the class cache produces 11 failures, with
direct cross-tenant evidence —

thread 23 saw ['user-A-secret', 'user-B-secret', 'thread-23']

Memory: the cache stores code objects, never ASTs — 18.4 KB per entry, 9.4 MB at
maxsize=512. An AST-retaining cache would be roughly 260 MB.

Deliberately not included

test_vertex_with_nothing_to_load_does_not_touch_the_connection_pool guards the
early return in update_params_with_load_from_db_fields. It belongs with a
loading.py change, not this one.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}