Measuring and Reducing MMapper Latency

[KasparMetsa]

Motivation

In competitive PK, every millisecond counts. Many veteran players have long held that JMC 3.26 (without VBScripts) is the fastest possible mud client setup for MUME. That claim has never been properly measured.

It would be valuable to quantify MMapper's proxy overhead so we can:

• Compare it against a direct connection (no proxy)
• Identify where latency is spent inside MMapper
• Reduce unnecessary overhead where possible

The goal is not to eliminate all overhead — MMapper does significantly more processing
than a raw telnet client (XML parsing, pathfinding, map rendering, group management).
But we should know the cost and avoid paying more than necessary.

MMapper's Processing Pipeline

Every line from MUME passes through this chain before reaching the client:

MUME Server
  → MudSocket          (TCP/SSL/WebSocket read)
  → MudTelnet          (Telnet IAC parsing, GMCP negotiation)
  → TelnetLineFilter   (Line buffering, CRLF handling)
  → MumeXmlParser      (Character-by-character XML parsing)
  → AbstractParser     (Room detection, command matching)
  → PathMachine        (A* pathfinding for auto-mapping)
  → MapCanvas          (OpenGL map rendering)
  → GroupManager       (Group/GMCP updates)
  → UserTelnet         (Telnet encoding for client)
  → UserSocket         (Write to client)

The likely bottlenecks are the XML parser (character-by-character processing),
pathfinding (A* search on the room graph), and map rendering (OpenGL draw calls).

Proposed Measurement Approaches

1. End-to-end: Camera-based measurement

Follow the approach used by hardware latency reviewers: record keyboard and screen with
a high-speed camera. Count frames between keypress and visible output. This gives the
most realistic measurement of what a player actually experiences.

Configurations to compare:

• JMC 3.26 → MUME directly (baseline)
• JMC 3.26 → MMapper proxy → MUME
• MMapper built-in client → MUME

2. Internal: Proxy processing time

Since hardware differences can skew end-to-end results, also measure a controlled
internal metric: time from receiving a line from MUME to writing the processed output
to the client socket. This isolates MMapper's overhead from display rendering, OS
scheduling, and network variance.

MMapper already has a DECL_TIMER macro (src/global/Timer.h) using
std::chrono::steady_clock, currently used in map rendering and pathfinding. The parser
pipeline (MumeXmlParser, AbstractParser, Proxy) does not currently have timing
instrumentation — adding it to the critical path would give immediate visibility into
where time is spent.

Key measurement points to add:

Location	What it measures
MumeXmlParser::parse()	XML parsing overhead
PathMachine::slot_handleParseEvent()	Pathfinding cost
Proxy receive-to-send	Total proxy pipeline

3. Reproducible: Standalone benchmark harness

Create a small benchmark tool that removes all external variables:

• Fake MUME server — replays captured session data or sends synthetic room output
• Fake client — receives and discards processed output
• Metric — time to process N lines through the full pipeline

This would allow:

• Benchmarking different MMapper versions against each other
• Catching performance regressions in CI
• Testing the impact of specific changes (e.g., parser optimizations)

Open Questions

• What's an acceptable overhead target? (e.g., < 5ms per line? < 1ms?)
• Should map rendering be decoupled from the forwarding path so the client gets data
  before the canvas finishes drawing?
• Are there processing steps that could be deferred or made asynchronous without
  affecting correctness?
• Does the built-in client (ClientTelnet via VirtualSocket) have different latency
  characteristics than an external client connected via TCP?