What's the plan and timetable to fix Thunderbird performance at startup due to Lightning bugs and flaws
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
> 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?
> 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
>> 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!
>> tb-planning mailing list
>> tb-planning at mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning