You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typing in the chat message box on a livestream is very laggy with PocketTube enabled. It often takes several seconds for typed messages to catch up, and the tab frequently locks up while typing.
I did a quick performance analysis in Firefox, and found that a large amount of CPU time is spent in the DOM mutation callbacks for PocketTube. Popping chat out into its own window shifts the CPU time accounting from the livestream window to the chat window, indicating that it is indeed chat which is the root cause.
This makes sense - presumably every new chat message and every character pressed in the text box is triggering a series of DOM mutations (probably quite a few due to updating all the chat icons, at-replies, etc.), which then triggers a pathological performance case in PocketTube's code, probably re-traversing the DOM looking for elements it integrates with. I don't currently have time to dig any deeper into the call heatmap, but it should be replicable just by going to any livestream with an active chat.
Running PocketTube 16.3.17 on FF 132.0 x64 Win10, with uBO + SponsorBlock also running. Tested on three machines; sluggishness is worst on machines with lower single-thread performance.
The text was updated successfully, but these errors were encountered:
It's weird, I can't reproduce the behavior under my account and there is no similar requests. I'm not sure we can optimize mutations, it's required for proper extension working.
Typing in the chat message box on a livestream is very laggy with PocketTube enabled. It often takes several seconds for typed messages to catch up, and the tab frequently locks up while typing.
I did a quick performance analysis in Firefox, and found that a large amount of CPU time is spent in the DOM mutation callbacks for PocketTube. Popping chat out into its own window shifts the CPU time accounting from the livestream window to the chat window, indicating that it is indeed chat which is the root cause.
This makes sense - presumably every new chat message and every character pressed in the text box is triggering a series of DOM mutations (probably quite a few due to updating all the chat icons, at-replies, etc.), which then triggers a pathological performance case in PocketTube's code, probably re-traversing the DOM looking for elements it integrates with. I don't currently have time to dig any deeper into the call heatmap, but it should be replicable just by going to any livestream with an active chat.
Running PocketTube 16.3.17 on FF 132.0 x64 Win10, with uBO + SponsorBlock also running. Tested on three machines; sluggishness is worst on machines with lower single-thread performance.
The text was updated successfully, but these errors were encountered: