Open justinpotts opened 8 years ago
Currently our JS isn't as efficient as it should be, which is likely the reason behind this issue. This isn't the first time this has been reported, and we've all experienced it while browsing heavier sites. Looking into this.
After some investigation, I'm not entirely certain this is due to poor performance from the add-on. It seems that a potential cause of this issue previously may have been an excessive number of console logs happening at once or something similar. We should look into any way to quantify memory usage and add-on performance to truly know whether our add-on is hurting browser speed.
Relevant Links: https://developer.mozilla.org/en-US/Add-ons/Performance_best_practices_in_extensions
Lowered the time interval between data pushes so that memory isn't ever stored for very long in the add-on. Additionally, if a user now sets the preference so they aren't sending data to us, their data store which would send the info is removed every interval.
The above should likely be optimized so that users with sendData
flipped off never actually log the data to the separate store in the first place as well.
Okay looks like a majority of performance issues are stemming from ExtensionStorage.jsm which we are using to store data locally for the interface. We should probably be batching our storage so that calls aren't made so frequently.
Page load time now reduced to <2% increase with the add-on in #50
A 2% increase in page load time is probably okay for v1. Although getAdNetwork is not efficient at all and should definitely be run server-side (or with batching as well), we can worry about this after more p1's get tackled for this sprint.
Leaving the thread open so we can discuss further optimization progress, but I'll move this to tracking and away from p1.
This also affects things like scrolling, changing tabs, and navigating pages.