> I'm imaging more along the lines of serializing editor state with each key press, encoding it, sending it to another process, having that process unserialize it, lex it, encode all of the cascading token changes and information about those tokens back into JSON, sending it back to the editor process which then has to decode the JSON and apply all of the token information to the in-memory representation as real overhead.
The latency of both Unix IPC calls and serialization/deserialization of small amounts of JSON should be measured in single- to double-digit microseconds. A frame at 60fps is 16,000 microseconds, so if this is causing even a single dropped frame, something is seriously wrong.
The lexing itself might or might not be a performance worry, depending on the architecture of the whole system, but that's no different from the lexing built into the editor (except perhaps in that people writing editors tend to care more about latency)...
(Well, this seems academic, since according to other comments RLS doesn't aim to put syntax highlighting out of process.)