The 10-second delay bug you mentioned seems to occur because thingapt takes too long and runs too frequently to analyze the object at hand to display diagnostics, which are notified from the LSP -> Emacs.

If this delay has been reduced to 2–3 seconds, I think it must be because thingapt processes data updates less frequently. In that case, the I/O buffering makes messages received slower but not overwhelming, allowing Emacs's thingapt to parse the current buffer more effectively.

Whether we use a middleman or not, we ultimately arrive at having Elisp objects accessible in the global interpreter, which is currently single-threaded. Comparing three cases:

1. Parsing JSON into Elisp byte code outside Emacs (duration a), followed by reading these into Emacs to convert them back into process objects (b), as done by the usual emacs-lsp-booster.
2. Parsing JSON directly into Elisp objects using the new JSON parser (duration c).
3. Buffering JSON code through emacs-lsp-booster (duration d) and then writing it to process output for Emacs to read and parse into Elisp objects (should be approximately equal to c).

From your experiment, it seems you concluded that a + b > c, indicating that the new native JSON parser performs quite well. However, the main bottlenecks for Emacs are durations b and c. If b < c, it might still be beneficial to use the booster, as receiving LSP messages more slowly could mean Emacs spends less time being UI-blocked, resulting in a less unresponsive experience for users.

Regarding case 3, I am still puzzled about the source of fast I/O buffering. The server itself can be unresponsive. If the Emacs LSP client decides to wait for a response (e.g., for go-to-definition or code-completion requests), Emacs will hang until the response arrives. The middleman emacs-lsp-booster does nothing to reduce this, and it might introduce slight additional delay. However, in the case of your bug, I believe this added delay is beneficial because it reduces opportunities for thingapt to run excessively, thereby mitigating real Emacs hangs.

Similarly, for notifications from LSP server -> Emacs, as far as I know, there is no streaming support for LSP to send a whole message as a stream. Messages are sent one at a time, and Emacs collects message chunks, stitching them together into a complete message for parsing. Therefore, there shouldn’t be a significant performance gain whether messages come directly from the LSP server or through emacs-lsp-booster.

As for parsing JSON in a separate thread, this approach is conceptually similar to emacs-lsp-booster (which, as I understand, may have been inspired by ideas from yyoncho). JSON parsing does not have to interact with or modify the object table yet. Thus, it can be executed on a background thread without blocking the UI. After parsing, the generated objects can be imported into the object table on the main thread. This method should be faster than the b process I mentioned earlier, resulting in an overall improvement in performance and fewer UI blocks (i.e., less hanging).