<div dir="ltr"><div dir="ltr"><br></div><div>Hi Magnus, <br></div><div><br></div><div>Thanks for your time and reply...</div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Date: Thu, 18 Jul 2019 14:05:18 +0300<br>
From: Magnus Melin <<a href="mailto:mkmelin%2Bmozilla@iki.fi" target="_blank">mkmelin+mozilla@iki.fi</a>><br>
<br>
Performance improvements are indeed high on the priority list.</blockquote><div><br></div><div>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...</div><div><br></div><div>What the plan to improve performance in the next 3 to 6 months?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br></blockquote><div><br></div><div>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 then?<br></div><div><br></div><div>As a possible plan in parallel of this "grand design", you may want to collect (as already started in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=487832">https://bugzilla.mozilla.org/show_bug.cgi?id=487832</a> 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...<br></div><div><br></div><div>Perhaps some of the performance issue could already be looked at and fixed today (as the 1st front of battle). Bug 
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1502923" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1502923</a> 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...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Like you noticed, there are many individual smaller things that can add <br>
up, and there's generally no magic bullet to just it all fixed at once.? <br></blockquote><div><br></div><div>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...<br></div><div><br></div><div>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...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
OTOH, there are some larger topics like making proper use of multiple <br>
processes, process per tab like Firefox, that have potential to speed <br>
things up significantly.</blockquote><div><br></div><div>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... <br></div><div>There may not be one case fit all situation here... <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I don't have detailed timetable for that, though I'm hoping we can get there in 1-2 ESR releases.<br></blockquote><div><br></div><div>Would it be a good time to get some details and timetable to evaluate progress? <br></div><div>And if not on the "grand design" plan, on small perf issues that could be already sorted?</div><div><br></div><div></div><div>How long 1-2 ESR represent... 6 months... 1 year? <br>Can Thunderbird wait another 6 months before its performance starts improving? Lighting related especially?<br></div><div><br></div><div>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  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1477958">https://bugzilla.mozilla.org/show_bug.cgi?id=1477958</a>) 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...<br></div><div><br></div><div>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? <br>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...</div><div><br></div><div>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...<br></div><div><br></div><div>Performance remain a critical issue for end-users and therefore a balance may need to be found between:</div><div>- a short term plan (1st front of battle) with immediate visible result/progress...<br>and</div><div>- a long term plan (2nd front of battle) to eliminate and prevent perf issues in the future... <br></div><div><br></div><div>One plan shall not prevent the other... or delay it...</div><div></div><div><br></div><div>Regards,<br></div></div></div></div>