Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I generally run with at least 100 tabs and have noticed that TST consumes a considerable amount of resources even when the system is idle. This has really impacted my battery life. I love TST though, so I really don't want to disable it. Consequently, I've begun profiling the extension using the Firefox Profiler.
For the current pass, I've been looking at heartbeat messages. They trigger all the time, even when idle, so they would ideally consume minimal resources. I found the message dispatch system accounted for 60%+ of all allocations. After stepping through the code with a debugger, I found that none of the registered
onMessage
handlers do anything with heartbeat messages. I suppose the idea was to keep the architecture clean and maybe allow for some handler to handle heartbeat messages in the future, but it's currently a fairly expensive no-op loop. This PR attempts to address this overhead in two ways:receiver
method in the sidebar connection. By sending the heartbeat message directly, we don't need to allocate arrays and invoke iterators to process batch messages.The code I replaced to post the heartbeat message by itself had a comment about not wanting to cause the UI to freeze. I don't know enough about web extensions to understand what the original problem was. I'm reasonably positive the heartbeat messages won't happen frequently enough to cause the UI to freeze. My understanding is this all runs on the same thread, so even if a non-heartbeat message comes immediately before or immediately after, the performance shouldn't be any worse on that batch operation than if the heartbeat message appeared in the batch. At least, these are the assumptions I've made. I'd appreciate if someone could evaluate them (and the code comment) I left for accuracy.