The new profile https://share.firefox.dev/362rRZW confirms that the patch is working as intended. `ConsoleOutput.render` is now 2.2% of the runtime section of interest. There aren't other obvious large blocks to pursue. Here's some relevant items: ``` Frame.render: 6.4% Message.render: 7.1% MessageContainer.render: 7.8% ConsoleOutput.render: 2.2% ``` The rendering methods combined are now about 23% of the runtime -- comparable to the gains already achieved by the reduction to time spent in `ConsoleOutput.render`. Even if we could somehow reduce render to 0s, we'd only shorten runtime by that much. There aren't obvious bad call patterns here. ``` MessageContainer.shouldComponentUpdate: 4.1% ``` There might be gains to be made here. The `shouldComponentUpdate` method should always be fast in order to be useful. Otherwise, just always update! ``` Document.createElementNS: 2.4% ``` This is cost of modifying the DOM. ``` PresShell::FlushPendingNotifications: 5.5% ``` This is our layout cost. Seems reasonable. This is evidence that virtualized scrolling is not relevant to this slow case. ``` ActivityStreamProvider.getTopFrecentSites: 2.8% ``` I have no idea what this is doing here. Even if it's just a coincidence that this scheduled operation overlapped with my profile, it's still true that this operation is much slower than it should be. ``` messages reducer: 4.7% ``` This is split between time in `addMessages` and `cloneState`. There may be opportunities here. Okay, that's not everything, but it's all the notable chunks that we might be able to affect. I'll see if I can add something in this patch stack to reduce time in `MessageContainer.shouldComponentUpdate` and in the messages reducer. I don't know what to do about `ActivityStreamProvider.getTopFrecentSites`.
Bug 1659773 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The new profile https://share.firefox.dev/362rRZW confirms that the patch is working as intended. `ConsoleOutput.render` is now 2.2% of the runtime section of interest. There aren't other obvious large blocks to pursue. Here's some relevant items: ``` Frame.render: 6.4% Message.render: 7.1% MessageContainer.render: 7.8% ConsoleOutput.render: 2.2% ``` The rendering methods combined are now about 23% of the runtime -- comparable to the gains already achieved by the reduction to time spent in `ConsoleOutput.render`. Even if we could somehow reduce render to 0s, we'd only shorten runtime by that much. There aren't obvious bad call patterns here. ``` MessageContainer.shouldComponentUpdate: 4.1% ``` There might be gains to be made here. The `shouldComponentUpdate` method should always be fast in order to be useful. Otherwise, just always update! ``` Document.createElementNS: 2.4% ``` This is cost of modifying the DOM. ``` PresShell::FlushPendingNotifications: 5.5% ``` This is our layout cost. Seems reasonable, though we might be able to reduce it by calculating the height of each console item (after initial layout). This is evidence that virtualized scrolling is not relevant to this slow case. ``` ActivityStreamProvider.getTopFrecentSites: 2.8% ``` I have no idea what this is doing here. Even if it's just a coincidence that this scheduled operation overlapped with my profile, it's still true that this operation is much slower than it should be. ``` messages reducer: 4.7% ``` This is split between time in `addMessages` and `cloneState`. There may be opportunities here. Okay, that's not everything, but it's all the notable chunks that we might be able to affect. I'll see if I can add something in this patch stack to reduce time in `MessageContainer.shouldComponentUpdate` and in the messages reducer. I don't know what to do about `ActivityStreamProvider.getTopFrecentSites`.