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
fix: reduce memory and cpu usage while running background queue #379
Conversation
Pull request title looks good 👍! If this pull request gets merged, it will cause a new release of the software. Example: If this project's latest release version is All merged pull requests will eventually get deployed. But some types of pull requests will trigger a deployment (such as features and bug fixes) while some pull requests will wait to get deployed until a later time. This project uses a special format for pull requests titles. Expand this section to learn more (expand by clicking the ᐅ symbol on the left side of this sentence)...This project uses a special format for pull requests titles. Don't worry, it's easy! This pull request title should be in this format:
If your pull request introduces breaking changes to the code, use this format:
where
Examples:
Need more examples? Want to learn more about this format? Check out the official docs. Note: If your pull request does multiple things such as adding a feature and makes changes to the CI server and fixes some bugs then you might want to consider splitting this pull request up into multiple smaller pull requests. |
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
PR implementation changed so I asked for a re-review. I updated the PR description talking about it. |
@@ -13,20 +13,13 @@ public protocol QueueRunner: AutoMockable { | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file contains the most changes for the PR. I moved code from Tracking module's QueueRunner into this one. Now, all of the Tracking API HTTP calls are in 1 module (which, I think is a good thing thinking about modularity in the code base).
@@ -0,0 +1,16 @@ | |||
import Foundation | |||
|
|||
public struct DeletePushNotificationQueueTaskData: Codable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of files in this PR are structs that git says are new files.
They are not new, they are moved and I modified them from internal
to public
so code in tracking module could access them.
case identifyProfile | ||
case trackEvent | ||
case registerPushToken | ||
case deletePushToken | ||
case trackPushMetric |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of moving code from Tracking QueueRunner into 1 QueueRunner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I understand. Please correct me If I am wrong and ask for a re-review.
Before we had two Queue Runners, one in common and one in tracking. We utilized hooks to communicate between modules (common and tracking).
Now with this change, we are getting rid of the Queue runner in the tracking module and shifting all the logic from there to the common queue logic also moved the data models from tracking to common so they can be utilized in the updated Queue runner in common.
So there is no new code that is being added but rather code being shifted from one module to another and we are getting rid of a particular hook that was used for this purpose.
@Shahroz16, 100% correct. I couldn't have put it better myself. Communication between modules is valuable and does help us keep our SDKs lightweight and modular. There is value in it. However, I no longer believe that a QueueRunner is the best use of the hooks feature. Originally, separate QueueRunners were to try and keep the SDK extra slim by putting specific Track API calls into modules that use them. But, doing that has added more complexity then what it's worth. Also, from internal discussions we have had about splitting our Common module into more modules, we have mentioned having a module that contains all HTTP code for communicating with the Track API. So, I see a day where all CIO Track API code is in 1 module. Therefore, another reason to not spread Track API code across modules. By this PR, we receive a performance gain in the SDK while also putting all Track API code into 1 module, which we can then split into it's own module in the future. |
## [2.8.2](2.8.1...2.8.2) (2023-09-07) ### Bug Fixes * reduce memory and cpu usage while running background queue ([#379](#379)) ([87a7eed](87a7eed))
part of: https://github.com/customerio/issues/issues/10950
While profiling the SDK, I noticed that the
QueueRunner
was using a lot of resources while the BQ executed. I found that for every background task item that was executed, a lot of new dependencies were being created because a newQueueRunner
instance (and it's subdepenencies) were being constructed by the hooks manager.I tried a couple of solutions to prevent new
QueueRunner
instances being created for each BQ task execution, but each solution I came up with would introduce a new edge case to the BQ execution where tasks might not get picked up by aQueueRunner
instance with hooks.Instead, I added commits later on in this branch that introduced the solution of no longer using hooks for executing the background queue. I don't see a reason to use hooks for BQ execution in the long-term and because it's what is causing the issues fixed by this PR, I removed them.