What's the plan and timetable to fix Thunderbird performance at startup due to Lightning bugs and flaws

Wayne Mery vseerror at lehigh.edu
Thu Jul 18 15:40:48 UTC 2019


On 7/18/2019 7:05 AM, Magnus Melin wrote:
>
> Performance improvements are indeed high on the priority list. The 
> first step will be to get some tests for UI performance so that we can 
> measure what progress we make (and don't regress). We should have some 
> of these later this year.
>
Why should tests block fixing bugs, which in some cases prevent users 
from using Calendar, or keep users on an older version Thunderbird/Calendar?

And are you suggesting we need to make the switch to ical.js 
<https://bugzilla.mozilla.org/show_bug.cgi?id=978570> before making 
further tweaks?


> Like you noticed, there are many individual smaller things that can 
> add up, and there's generally no magic bullet to just it all fixed at 
> once.  OTOH, there are some larger topics like making proper use of 
> multiple processes, process per tab like Firefox, that have potential 
> to speed things up significantly. I don't have detailed timetable for 
> that, though I'm hoping we can get there in 1-2 ESR releases.
>
You're not suggesting not waiting 1-2 ESR to fix perf improvements that 
don't require multiprocess, correct?


>  -Magnus
>
> On 18-07-2019 11:42, Richard LEGER wrote:
>> Dear Thunderbird (TB) team,
>>
>> Startup performance issues have been plaguing TB for years (7 years 
>> or more possibly) especially due to Lightning being enabled... and it 
>> became worth in past years...
>>
>> Up to now the "false" assumption has been that all I/O happens in one 
>> thread (ui, email core features in addition of Lightning) causing too 
>> much processing... not responding issues...
>>
>> While this may have been partially true, tremendous progress have 
>> been made so far in that regards within TB (e.g core improvements, 
>> use of workers and async features helping if I am not mistaking), so 
>> it had been more an aggravation of existing underlying issues in 
>> Lightning than a root cause.
>>
>> Indeed I think such progress shadows the fact that Lightning still 
>> contains bugs and design flaws (no blame on developers here) that are 
>> mainly source of performance issues especially at startup that are 
>> still not being analysed and addressed the way they should (at least 
>> from end-users point of view) by implementing long term 
>> fixes/solutions into that code so it would performs "normally" ;-)
>>
>> As an end-user, month ago, I have revealed (because end-users could 
>> not take it any more!) bug 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1502923 (patch issued 
>> but backed out without further support) and bug 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1543953 as the tip of 
>> the iceberg but received barely any support from TB/Lightning dev 
>> teams so far or feedback on helping resolving those long lasting and 
>> highlighted performance issues. It may not be a priority for 
>> developers (in their time and resources constraints) but it IS for 
>> many end-users...
>> [Update: there might be light at the end of the tunnel as per new bug 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1567055 created today]
>>
>> From my impression, while it seems that lot of efforts (and 
>> communication) are oriented new UI revamping and new features... bugs 
>> fixing and especially those related to performance (quality, 
>> reliability, speed) seems relegated to a lower priority to some 
>> extent... while it should be in reverse order...
>>
>> Currently are code reviews and new features subject to large scaling 
>> tests to assess performance of code with large data sets prior 
>> publishing it?
>> Are performance issues detected (or reported) fixed immediately or 
>> right after in next dev cycles?
>>
>> For two years TB quality and reliability had decreased drastically, 
>> mainly due to lengthy discussion about governance that put TB 
>> development and maintenance to a stall, it was kept afloat by the 
>> remaining dev team and community (great thanks to them!).
>>
>> As it is now past, shouldn't 2019 be the year where TB reliability 
>> and performance are brought back to life and take priority over new 
>> features? Wouldn't that be the best way to bring back confidence (and 
>> contributors) in the project? Wasn't it the priority for 2019 "Making 
>> Thunderbird fly faster" in the first place, as I recall?
>>
>> Now that a new team is up and running, what is the plan to tackle 
>> reliability and performance issues in TB especially those linked to 
>> Lightning?
>>
>> Would (and could) time and resources be dedicated to them in 
>> particular so they can finally be fixed once and for all in the next 
>> few months?
>>
>> While Lightning is an add-on it provide a calendar features to TB and 
>> therefore shall be considered as an essential Core feature that need 
>> much care and attention ;-) I am not saying it is not already 
>> (because it certainly is)... just that it needs much more... 
>> especially performance wise...
>>
>> As of today it is still not possible to have 4-5 calDav calendars 
>> (with thousands of items each) enabled and active at the same time, 
>> above two, it cripples TB especially at startup...
>>
>> Maybe a plan and timetable is already in place if that the case, 
>> please advise and communicate on what can be expected...
>> Otherwise could a plan and timetable be established with clear goals 
>> and results to clear any performance issues in TB due to Lightning 
>> especially, as a priority?
>>
>> It may be a wishful thinking but plan, support and fixes on the 
>> performance matters would be greatly appreciated by end-users...
>>
>> Looking forward to seeing Thunderbird fly fast in 2019!
>>
>> Regards,
>> Richard
>>
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190718/240bd6a5/attachment-0001.html>


More information about the tb-planning mailing list