quoid
Investigate extension energy consumption anomalies
There is a review in the App Store:
调用safari的时候插件能耗激增 评论人：comet111111 – 2023年10月11日 mac sonoma，从其他程序转到safari的时候，插件的能耗瞬间增长到600 ，之后恢复正常。工作过程中需要频繁在其他程序和safari之间跳转，导致耗电明显加快
The user reported that in v4.4.4, possibly after the improvement of #525, they found that the energy consumption was abnormal when switching to Safari, and the energy consumption value in the activity monitor reached 600.
Initial local testing, however, was unable to reproduce the problem, and even with multiple tests containing nearly 20 scripts, the energy consumption value topped out at just around 10. In all other operations, the peak energy consumption hardly exceeds 200.
Since the user does not provide specific usage scenarios, and contextual information such as script type and number, it is not possible to target debugging and reproduce the problem. However, this issue is recorded here if we have the opportunity to be able to get more information or to keep an eye on and investigate the issue, as well as look for ways and spaces for improvement.
Hello, this user is me. Thank you for paying attention to this issue.
I added about 10 scripts, and after my troubleshooting, it was the following script that caused the problem (the same is true of disabling it, and returning to normal after deleting it):
https://greasyfork.org/scripts/370246-sci-hub-button/code/Sci-hub%20button.user.js
(In addition, I noticed that Userscripts also triggers 20-40% resource consumption when opening a Web page that doesn't require calling scripts. I don't know if this is a normal expectation.)
It looks like the script has a fairly large header, but I'm still not sure exactly what's causing the problem and will require further in-depth investigation and debugging.
But to answer your second question first, due to the way the extension works, on every page load it injects the content script and checks if there is any user script that needs to be injected, so it still requires some resources.
But I'm not sure what you mean by "20-40% resource"?
Maybe my expression is wrong. It’s the “Impact on energy consumption” value in Activity Monitor. I don’t know which unit should be used to express it.
@CometYZ Hello, I have used the script you provided for repeated local testing, but the abnormal energy consumption still cannot be reproduced. After installing the script, the energy consumption value increased, but still could not exceed 20.
More specifically, while repeatedly switching the focus between Safari and the activity monitor, this action reflecting an energy consumption value of the extension just around 10-20. But Safari itself has an energy consumption value of about 200-300 (even if I completely disable the extension), which is comparable to the Activity Monitor itself.
However, I can observe higher values when scrolling this script up and down in the editor of the extension page, with peaks that can exceed 1000. (But I don't think that's the scene you're talking about.)
For reference, can you provide a screen recording showing your observation process? It would be best to include changes in the overall energy consumption of the Extension, Safari, and Activity Monitor itself.
https://drive.google.com/file/d/1mQ6jYM07bw6YQGIuX9YmYUbHUCe4ZHDw/view?usp=share_link By the way, my computer is Macbook Air M1 Sonoma 14.0, which turns on the Stage Manager.
@CometYZ Thank you for the information. Now I know, I was observing the wrong process. And yes, I can reproduce the same or even higher values than you.
I believe this is the correct rendering. Based on my previous brief speculation, due to the large size of the script (head and body), it would take proportionately more resources to parse it each time.
Compared with instantaneous energy impact value, I believe that CPU Time is a more intuitive and obvious reference value.
All things considered, there's probably no easy way around this without breaking existing functionality and experience. To completely solve this problem, overall process optimization is required to reduce the calculations required in each process. This means a lot of refactoring work, some of which we are also working on.
However, thank you for your feedback on this issue, which will serve as one of the important reference standards for our subsequent reconstruction work.
I think I've come up with a way to quickly ease the calculations by checking when the file was last updated, rather than parsing its contents each time.
But this means some structural changes and relies on another issue that needs improvement.
Just recording this idea, I will try and reconstruct it in the near future.