Performance issues have been pointed out in bug 1049967, specifically: http://robertovitillo.com/2014/10/07/using-ml-to-correlate-add-ons-to-performance-bottlenecks/ and http://robertovitillo.com/2014/10/16/correlating-add-ons-to-slow-shutdown-times/ Since the addon is also in the partner builds, we need to work with Yandex to address the issue, they'll likely need some input and guidance from us.
Danil, do you work on the Yandex extension?
The following stacktrace seems to be the main offender: YandexDisk.prototype.version() @ integration.js:290 js::RunScript js::RunScript dayuseDataCollector__calcYaDisk() @ dayuse.js:325 dayuseDataCollector__calcCommonData() @ dayuse.js:248 elmntDayuseDataCollector_collect() @ dayuse.js:432 dayuse__collectData() @ dayuse.js:134 dayuse__logData() @ dayuse.js:111 dayuse_notify() @ dayuse.js:59 js::RunScript js::RunScript Timer::Fire Danil, any thoughts on how to improve startup time? I used the Gecko Profiler to get that stacktrace (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler) during startup.
'dayuse__logData' starting not earlier than 1 minute after 'dayuse' module load. This should not affect the startup time. Anyway, I'll check this place, thank you. I guess that I'm found the main reason of slow startup at least in Mac OS and will write about it later.
(In reply to Danil Ivanov from comment #4) > 'dayuse__logData' starting not earlier than 1 minute after 'dayuse' module > load. This should not affect the startup time. Anyway, I'll check this > place, thank you. According to the profiler that stacktrace appeared during the first 5 seconds on startup. > I guess that I'm found the main reason of slow startup at least in Mac OS > and will write about it later. That's great news!
Danil, what is the status on this bug? Thanks, Shane
Shane, Some of the most problematic code was fixed in the 8.8.0 version (not in update channel). For example, More lazy loading some parts of extension and modules. Improvement of custom protocol ("xb://") implementation. Drop <em:unpack>true</em:unpack> with some changes to work correctly without unpacking. nsIDNSService.asyncResolve instead of nsIDNSService.resolve (oh, it was at the start). More async database queries. 8.8.1 with patch for better fx36 support will be in the update channel in this week. We do not stop working on the identification of bottlenecks and will improve the speed in future versions.
Danil, that sounds great. Could you post on this bug when 8.8.1 is available, then perhaps @rvitillo can take another look and see if there is any further issue. Best Regards, Shane
OK, I'll post
https://download.yandex.ru/element/firefox/upYandexElement-881.xpi Today update was turned on for 10% of users.
@rvitillo, when you have a chance, can you take a look at the performance again?
Flags: needinfo?(mash) → needinfo?(rvitillo)
We are going to have to wait a while to rerun the analysis on Telemetry as we need more data. What I can tell you right now is that with the updated Yandex add-on the startup time is still about 1.7 to 2 times higher than without it on my rather high-end machine. Danil, you can inspect the startup time yourself in the about:telemetry tab, under "Simple Measurements" -> "firstPaint".
still an issue?
I'm not really on this any more, passing to mkaply
Flags: needinfo?(mixedpuppy) → needinfo?(mozilla)
They are moving to WebExtension. I don't think there is anything to do here anymore...
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.