What's the plan and timetable to fix Thunderbird performance at startup due to Lightning bugs and flaws
richard.leger at gmail.com
Fri Jul 19 12:49:15 UTC 2019
Thanks for your time and reply...
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...
What the plan to improve performance in the next 3 to 6 months?
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.
While this is certainly an essential step forward that is much welcomed, it
should not be considered the first step (and only step) especially
considering it would take another 6 months to put in place! Which mean
another 6 months (roughly) from then to start seeing some results... so 1
year in total... Is it really not possible to improve performance before
As a possible plan in parallel of this "grand design", you may want to
collect (as already started in
https://bugzilla.mozilla.org/show_bug.cgi?id=487832 tb-startupperf [meta]
Thunderbird startup performance issues), analyse, and then distinguish
between the various performance issues reported perhaps... not all may be
related to the UI Performance itself but rather to underlying code bugs and
flaws. No all perf bugs may need 6 months or more waiting to be fixed. You
may want to battle on two fronts here...
Perhaps some of the performance issue could already be looked at and fixed
today (as the 1st front of battle). Bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1502923 is only one example
that may shows that changing a small peace of underlying code can have a
HUGE performance improvement... but it require attention to perf bugs, time
and resources... and further troubleshooting and testing... unfortunately
patch for 67.x branch was backed out due to regression in 68.x where
Lighting code changed very much already... so 67.x patch would not longer
"fit"... now it could be a matter of tackling this regression to fix it
possibly and to allow publication of a patch shortly... but again that may
mean to put as a priority with resources and support to tackle such long
lasting "major" perf issues that only require a "small" fix...
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.?
While it is understandable perf issues cannot all be all tackled at once,
they could be collected and analysed to see what could be already sorted
and distinguished from what might require a grant re(design)... and those
not (already fixable at next dev cycle iterations)... Then go step by step
to fix perf issues one by one (where already possible of course) until
greater goal is achieved... or getting closer to it... with a clear and
transparent progression path...
This again may require time and resources, maybe a dedicated team
temporarily could have a look at all perf issues... and see what could
already be tackled and crack down... maybe by highlighting and narrowing
down issues... maybe also helping raising awareness about perf issues
within the dev teams responsible for the area of code affecting perf, so
they look at it in their own code or part of their current ongoing code
review... just a thought... from end-users point... but all this may
already be in place...
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.
Yes there are some larger topics that are already getting some attention
that will fix part of the perf issues, and that is great long term plan,
but as shown performance bugs may not be directly linked to those issues
and may already be fixable to some extend if look after already... by
fixing existing code...within a short term plan...
There may not be one case fit all situation here...
I don't have detailed timetable for that, though I'm hoping we can get
> there in 1-2 ESR releases.
Would it be a good time to get some details and timetable to evaluate
And if not on the "grand design" plan, on small perf issues that could be
How long 1-2 ESR represent... 6 months... 1 year?
Can Thunderbird wait another 6 months before its performance starts
improving? Lighting related especially?
It would be expected to see at least slight performance improvements during
the next 6 months of development... for the sake of end-users...
workarounds such as lazy loading (e.g
https://bugzilla.mozilla.org/show_bug.cgi?id=1477958) may be welcomed as
they may help hinder performance issues in short term (as part of the
solution) but keeping in mind they would not fix underlying bugs and code
flaws... it may only "hide" them deeper...
Not all has to be fixed at once, I don't even think it is even possible
honestly :-) but are they really no ways to already bring some perf
improvements into TB?
Any that would appear progressively at each next releases during the next 6
months? End-users may expect it as a "feature" and it should be considered
as such, each release making the software perform better and better... in
parallel of bug fixes and new features... that would be great news... at
least to tide you over while more to come...
I am just trying to raise awareness here... that some perf issues may
potentially be already addressable... without much waiting... it may just
be a matter of looking into it...
Performance remain a critical issue for end-users and therefore a balance
may need to be found between:
- a short term plan (1st front of battle) with immediate visible
- a long term plan (2nd front of battle) to eliminate and prevent perf
issues in the future...
One plan shall not prevent the other... or delay it...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning