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

Richard LEGER richard.leger at gmail.com
Wed Oct 23 08:45:49 UTC 2019


On Fri, Jul 19, 2019 at 1:49 PM Richard LEGER <richard.leger at gmail.com>

> Date: Thu, 18 Jul 2019 14:05:18 +0300
>> From: Magnus Melin <mkmelin+mozilla at iki.fi>
>> Performance improvements are indeed high on the priority list.
> It is good to hear about it, Thunderbird team should communicate more
> regularly in details about plans to tackle performance issues, maybe via a
> dedicated blog posts perhaps? Just a suggestion...
A lot was heard about new core features of TB (or removed ones) but what
about reliability and performance improvements?
Reliability and performance are what put people off Thunderbird in the
first place, much much much more than UX theme/layout issues or missing
features among others...

So any news about those?
What is happening on those fronts?
What has improved in the past 3 months? What will improve in the next 3

At the meantime, I would like to praise the calendar dev team for bringing
quite some improvements to the calendar feature...

In 70.x branch and later (results here
https://bugzilla.mozilla.org/show_bug.cgi?id=1572823#c16 and here
https://bugzilla.mozilla.org/show_bug.cgi?id=1572823#c19), it now only take
1mn+ with libical (or 2mn+ with ical.js) to load a CalDAV network calendar
with ~4000 items... compared to the 100mn+ in 60.x branch that is quite an
achievement!!! Bravo!

That said, efforts must continue and results must continue to improve in
the course of next months, much before 76.x version foreseen in summer
2020... so far 72.x branch has not shown further improvements (yet) on that
front compare to 70.x branch... and ical.js seems not performing as well or
better than libical (yet)...

Would fixing bug https://bugzilla.mozilla.org/show_bug.cgi?id=1543953 be a
way forward (or not) by reducing number of network requests... while
waiting for ical.js and UI performance measurement and improvements? That
remain to be seen...

I hope everyone would agree and understand that 1mn+ is still way too much
of a delay to any end-user out there :-)
Especially considering that is preventing/delaying access to emails (via
IMAP) for several minutes at startup (issue reported here

Work in progress I know... and thank you all for this... but please keep up
and continue the good work...

End-users are very much looking already to such performance improvements...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191023/8973ca56/attachment.html>

More information about the tb-planning mailing list