[quaesitor-scientiam]

Problem

bin/update-vlang-graph.vsh builds the MCP server without -prod. Its comment says a -prod build takes 3 min 14 s and answers about as fast. Neither holds any more.

Since vlang/v#31382 ("macos: restore TCC defaults"), a plain build on macOS uses TCC again. After the update to V 4b1f3e2, bin/graphify-mcp went from 3.5 MB to 6.8 MB: TCC writes the zeroed globals of V's flat module (about 2 MB) into the file. It also got slower.

Measurements

macOS arm64, graphify 69b1e81, V 4b1f3e2. cmd/mcp was built three ways, and each binary ran three times without the daemon (GRAPHIFY_MCP_DAEMON=0) against the vlang graph. Startup is the time to the answer to initialize, loading the graph included. Each query is the median of 20 calls after a warm-up round.

	plain (TCC)	-cc clang, before #31382	-prod
build	3 s	about 30 s	29 s
size	6.8 MB	3.5 MB	1.6 MB
startup	6.8–7.5 s	3.7–4.7 s	1.1–1.3 s
get_node	15–17 ms	9.5 ms	4.5–5.3 ms
get_body	26–29 ms	34 ms	3.8–4.8 ms
shortest_path	16–19 ms	13 ms	3.9–4.7 ms
overview	176–226 ms	173–175 ms	46–55 ms
query_graph	308–358 ms	249–263 ms	64–81 ms

Change

• rebuild_if_stale builds the MCP server with -prod, as it does the CLI, and as the README's build steps already do. An update takes about 26 s longer.
• build_one's comment gives these figures in place of the old ones. The hook stays a plain build: it answers about as fast either way.

Tests

• v -check bin/update-vlang-graph.vsh, v test . and v run bin/test-crlf.vsh pass.
• On Windows, the updater already builds the CLI with -prod, so the MCP server builds with the same compiler there.

🤖 Generated with Claude Code