Hi, I just read a mail from some time ago which I seem to have missed before on this ML. It's from 2013-08-06: '[WebODF] 2 month performance blitz for webodf'. There is one thing I would like to add to the specific example of terrible performance of our yet unoptimized code in this regard. Philip gave the example of 500ms delay for deleting a single character. That is of course bad - but it is even worse: What does the Average Joe do to delete 5 words? Right! He would press AND HOLD the delete key and stops when the words are gone. Ever tried that in the 500ms scenario? The problem is that the key event is processed immediately and the browser is busy for the 500ms, and when the browser comes back from being so busy, there will be like 100 more key events queued. The problem is obvious: the browser will be busy again for 500ms x 100 times, without any time in between for anything else. In my opinion we need to separate the event-reading from the event-processing. The event processing needs to happen in a way which gives the browser a small time slot to take care of its other duties as well. So my proposal is to read the key-event; perhaps also create the resultant Op from it, but then just enqueue the Op for execution. Then we have a chance to do sane scheduling of Op execution and making sure the browser does not starve by giving it small time slots for survival. The effect is that the browser does not appear locked for a long period to the user, but instead the users will see one execution rendered before the next one starts. We had a similar effect when playing long lists of Ops. Changing this to "chunked" Op-replay improved things. PS: I am aware that the scheduling would not prevent the queue to fill with 100 key-events while the browser is busy in execution. But it will change the user perception from "browser dead - webodf crashed" - to "it is a bit slow down here". th -- Tobias Hintze // KO GmbH http://kogmbh.com/legal/