Performance and cost of filtering events #1891
Description
Problem statement
The filter function in Blockly.Events combines related events (e.g. two moves of the same block) and removes events that do not need to be sent over the wire for simultaneous editing. Events that are filtered out are never fired.
The goal is to reduce the number of events that needs to be sent over the wire, especially in cases when the two users were disconnected for long enough to build up a large queue.
This may be unnecessarily expensive when most of the events are not duplicates or when doing forseeably large batch operations, such as swapping sprites in Scratch. We have previously improved the behaviour of the filter function to make it much faster, but
The filter used to combine all move events without considering intervening events. This can be a problem if the intermediate events relied on the move (e.g. connecting over a shadow block and then disconnecting). This shows as a breakdown in undo/redo, but not in triggering action.
Possible solutions
- Disable filtering entirely
- Allow the developer to enable or disable filtering
- A developer who wants to send things over the wire or have heavyweight listeners would want filtering on
- A developer with lightweight listeners and lots of batch actions might want filtering off
To explore
- For some basic workflows, what percent of events are actually filtered out?
- Load workspace
- Clear workspace
- Are the current rules correct about which events get merged?
Test code
To disable filtering, replace the first few lines of Blockly.Events.fireNow_. Delete
var queue = Blockly.Events.filter(Blockly.Events.FIRE_QUEUE_, true);
Blockly.Events.FIRE_QUEUE_.length = 0;
and replace with
var queue = Blockly.Events.FIRE_QUEUE_;
Blockly.Events.FIRE_QUEUE_ = [];