I wonder if we could have some fast paths there. EditorBase::EndPlaceholderTransaction() and stuff under it take currently 12% of input.value setting.

Which method called from EndPlaceholderTransaction() is slow? If EditorBase::NotifyEditorObservers() is slow, we could make it faster with reducing nsIEditorObserver instances (we could make treat some of them as concrete classes).

It was many thing. I think I was profiling using Zoom, so sharing the profile isn't quite as easy as with Gecko profiler. I used Test 2 from bug 1346723 for testing.

After landing bug 1432528, I don't see EditorBase::NotifyEditorObservers in profile anymore: https://perfht.ml/2GkHVqL According to the profile, I see a lot of Selection related slowness. If editor can wrap accessing Selection and do it only necessary time, e.g., immediately before firing mutation events, input event and at last, we *might* save some cost from it though.

After fixing bug 1432528, I don't see EditorBase::EndPlaceholderTransaction() in my environment (https://perfht.ml/2GsUekS). Smaug, could you check it in your environment too? However, I still see a lot of method names related to Selection::Collapse() and Selection::NotifySelectionListeners(), although bug 1432528 got rid of a lot of selection listeners...

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #3) > According to the profile, I see a lot of Selection related slowness. If > editor can wrap accessing Selection and do it only necessary time, e.g., > immediately before firing mutation events, Well, we aren't firing any mutation events here. That would be slow. But yeah, EndPlaceholderTransaction isn't taking too much time now. Around 2% in my profile. I guess we can mark this one fixed.