Improve Serial Monitor Performances

[fstasi]

Why

Serial monitor is affected by performance issues: basically it's not able to keep up with the grpc messages arriving from the CLI when a decent amount of message (>100/sec) is being sent from the board.

There are a number of reasons causing this undesirable effect:

• the communication between Frontend and Backend is very chatty: the FE basically pulls a message at a time from the BE and gets notified when a new message arrives (see comment)
• The frontend re-renders the whole list of messages every time a new one is pulled
• JRPC is used to marshal/unmarshal the data, causing additional overhead to the messages
• all messages are aggregated (and then printed), without any limit to the maximum number

How

A new architecture for the communication has been designed:

• the backend collects the messages from the CLI and aggregates them in array.
• every 32 milliseconds the BE sends a chunk of message to the FE, containing all messages arrived in the 32msc timeframe. The reason behind the "32" milliseconds is the refresh rate of the electron application (32msec ~= 30fps). 16ms would guarantee a 60fps, but at the cost of more CPU and reduced responsiveness in the IDE2 GUI
• the communication between FE and BE is now a "raw" WebSocket connection, without the overhead of JRPC.
• as the frontend receives the chunk of messages, it adds them to its internal state, assigning them a timestamp and removing the old ones when the buffer size is reached
• the frontend renders only the messages that are actually in the monitor window: this allows to dramatically reduce the CPU usage as only a few messages are printed, rather than millions

How to test

• upload a sketch with Serial.print or Serial.println and use no delay in order to have a high throughput of data flowing from the board
• open the serial monitor in the IDE2

Related issues

fixes #391, fixes #79, fixes #519

[AlbyIanna]

🚀