Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More efficient heartbeats #3238

Merged
merged 2 commits into from
Oct 25, 2022
Merged

Conversation

nirvdrum
Copy link
Contributor

@nirvdrum nirvdrum commented Oct 25, 2022

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:

  • The sidebar connection, which already had a special case for heartbeat messages, no longer dispatches the heartbeat message when it is done with it, thus avoiding that unnecessary dispatch.
  • The heartbeat messages are sent using the same message passing system as all other messages, but that involves boxing into an array to batch process, then processing that array, which ends up making a recursive call into the 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.

None of the message handlers currently do anything with heartbeat messages, so the dispatch ends up being an expensive no-op.
Boxing the heartbeat message into an array causes the message to proceed down the general batch message processing path. By posting just the heartbeat message on its own, we can avoid the boxing and unboxing and iterating through the array, with all the memory allocation that entails. It also means the heartbeat messages can be responded to more quickly, which is advantageous in a watchdog system.
@piroor piroor merged commit d8823a7 into piroor:trunk Oct 25, 2022
@piroor
Copy link
Owner

piroor commented Oct 25, 2022

Thank you for detailed investigation! I totally agree that I did too much for heartbeats.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants