Skip to content

[Repo Assist] perf: replace map[string]interface{} with typed structs in RPC hot paths#2312

Draft
github-actions[bot] wants to merge 1 commit intomainfrom
repo-assist/perf-jsonrpc-request-struct-24627183e2071a07
Draft

[Repo Assist] perf: replace map[string]interface{} with typed structs in RPC hot paths#2312
github-actions[bot] wants to merge 1 commit intomainfrom
repo-assist/perf-jsonrpc-request-struct-24627183e2071a07

Conversation

@github-actions
Copy link
Contributor

🤖 This PR was created by Repo Assist, an automated AI assistant.

Summary

Replaces map[string]interface{} allocations on the JSON-RPC request hot path with typed structs, reducing per-call heap allocations and GC pressure.


Changes

internal/mcp/http_transport.gocreateJSONRPCRequest

Every outbound HTTP JSON-RPC request called createJSONRPCRequest, which allocated a map[string]interface{} just to marshal it into JSON bytes immediately afterward. Go maps always live on the heap (the internal hash table is heap-allocated), even for tiny maps with 4 entries.

Replaced with:

type jsonrpcRequest struct {
    JSONRPC string      `json:"jsonrpc"`
    ID      uint64      `json:"id"`
    Method  string      `json:"method"`
    Params  interface{} `json:"params"`
}

internal/mcp/connection.goSendRequestWithServerID

The outbound request log entry also built a map[string]interface{} on every call (for stdio and HTTP connections alike). Replaced with a dedicated jsonrpcLogPayload struct (no ID field since the log format doesn't include it).


Why It Helps

  • No map hash table allocation — struct values can be stack-allocated or inlined by the compiler; maps always escape to heap
  • Faster JSON marshaling — struct marshaling uses pre-computed field offsets and skips the map key type-assertion loop
  • Same wire formatencoding/json produces identical JSON output from both representations

For an MCP gateway that proxies every tool call through these paths, eliminating 2 heap allocations per request reduces GC frequency under load.


Tests Updated

TestCreateJSONRPCRequest and TestCreateJSONRPCRequest_HasAllRequiredFields updated to use struct field access (req.JSONRPC, req.ID, etc.) instead of map key lookups. TestCreateJSONRPCRequest_IsSerializable was unchanged (it round-trips through JSON).


Test Status

Infrastructure note: the Go module proxy is blocked in this agent environment (network firewall). Module cache is empty so go test cannot compile. The changes are structurally sound (correct JSON tags, consistent field types); CI will run the full test suite.

Generated by Repo Assist ·

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55

Warning

⚠️ Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

  • proxy.golang.org
  • releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "proxy.golang.org"
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.

Every outbound JSON-RPC call marshaled a freshly-allocated
map[string]interface{} to build the request envelope (http_transport.go)
and a second map in connection.go for the log payload. Go maps always
live on the heap because their internal hash table is heap-allocated,
even for small maps.

Replace both with typed structs:
  - jsonrpcRequest in http_transport.go (JSONRPC, ID, Method, Params)
  - jsonrpcLogPayload in connection.go (JSONRPC, Method, Params)

Typed structs can be allocated inline or on the stack by the compiler,
reducing GC pressure on the request hot path. JSON marshaling of structs
also skips the map iteration and key-type-assertion overhead, making it
faster for fixed-schema objects.

Update TestCreateJSONRPCRequest and TestCreateJSONRPCRequest_HasAllRequiredFields
to use struct field access instead of map key lookups.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants