Buffer sendResponseMessage and its variant methods

[jooskim]

Internal testing on VMware Cloud UI revealed that there are certain
conditions that could impact the performance of the Angular change
detection system, or any other frontend frameworks that rely on the
Event Loop of the JS engine.

Currently every message being sent via the sendResponseMessage(),
sendResponseMessageWithId() or
sendResponseMessageWithIdAndVersion() method is scheduled as a macro
task, which means send message logic shares CPU resources with other
macro tasks like DOM painting or other event handling. This way of
sharing the CPU single thread with other tasks usually is benign enough
not to cause much trouble if any.

However, if 1) the send message method is called in rapid succesion,
and 2) each macro task triggers a compute-intensive task such as a
complete re-render of the view like Angular with default change
detection strategy does, the UI will experience a significant
performance hit that looks like a tight loop that could be observed
in the Chrome Inspect Panel.

A sensible solution to the problem is to buffer the payload by a
certain interval and scheduling the macro tasks by chunks not by
every single entry. By doing this it will limit the impact to the
CPU because now the change detection will happen only as frequently
as the buffer is flushed.

See the attached benchmarks for comparisons in CPU utilization.

Signed-off-by: Josh Kim [email protected]

[jooskim]