<div dir="ltr"><div dir="ltr"><br></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"><div dir="ltr"><div dir="ltr"><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></div></div></blockquote><div><br></div><div>Hi Magnus,</div><div><br></div><div>Since you made the statement above, would you be able to highlight what has been achieved in term of Thunderbird performance improvements, as well as what is in the pipeline to fix design flaws that still affect TB performance especially at start-up? </div><div><br></div><div>What can we expect for the next stable version?</div><div><br></div><div>From my personal experience, from an end-users point of view so far, there still seems much to be done in term of visible results and I believe I may not be the only one to experience poor perf in TB... if I am please accept my sincere apology :-)</div><div><br></div><div>I know there is a plan to split processing in TB in different processes (as The Holly Grail toward a solution), which is coming up and that would be really nice to have, but that shall not be used to hide the performance bottleneck coming from the possible flaws in the TB code itself by design, and it is certainly not gonna be ready for the next stable(s)...</div><div><br></div><div>The same way while cache features have a side effect to improve performance, their main purpose by design is to allow access to the data offline and shall not be used as a permanent workaround to hide performance issues "under the carpet"... people shall be able to use TB in online mode without much more issues than in offline mode... even with large or very large data sets (the only limits shall be the physical ones network speed, storage space, etc...not TB itself) indeed not everyone may like data to be cached (copied/stored) on a local computer... or wait 2mn+ to be able to read first email at start-up!</div><div><br></div><div>Is there anyway results can be improved? How soon?</div><div>Is there anyway we can help? Better?</div><div><br></div><div>For now, I have recorded new performance profiles for various TB version in various setup that I can test with, and results can be found here:</div><div><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1649103#c52">https://bugzilla.mozilla.org/show_bug.cgi?id=1649103#c52</a> </div><div><br></div><div>I also put the links here for convenience...</div><div><ul>
<li>
<p>Blank profile - From startup till main UI appears<br>
TB 78.6.1 <a href="https://share.firefox.dev/2Ntqk8f" rel="nofollow">https://share.firefox.dev/2Ntqk8f</a><br>
TB 85.0b3 <a href="https://share.firefox.dev/2Y5s1uo" rel="nofollow">https://share.firefox.dev/2Y5s1uo</a></p>
</li>
<li>
<p>IMAP email only (all network calendar disabled) - From startup till first email can be read<br>
TB 78.6.1 <a href="https://share.firefox.dev/398G3C6" rel="nofollow">https://share.firefox.dev/398G3C6</a><br>
TB 85.0b3 <a href="https://share.firefox.dev/3sMXvnn" rel="nofollow">https://share.firefox.dev/3sMXvnn</a></p>
</li>
<li>
<p>IMAP email + calendar (cache enabled) - From startup till first email can be read<br>
TB 78.6.1 <a href="https://share.firefox.dev/39WEpSX" rel="nofollow">https://share.firefox.dev/39WEpSX</a><br>
TB 85.0b3 <a href="https://share.firefox.dev/3qUSgQX" rel="nofollow">https://share.firefox.dev/3qUSgQX</a></p>
</li>
<li>
<p>IMAP email + calendar (cache disabled) - From startup till 2mn30 - still not able to read my first email by then!<br>
TB 78.6.1 <a href="https://share.firefox.dev/3c86kCt" rel="nofollow">https://share.firefox.dev/3c86kCt</a><br>
TB 85.0b3 <a href="https://share.firefox.dev/2Y3etj7" rel="nofollow">https://share.firefox.dev/2Y3etj7</a></p>
</li>
</ul></div><div><br>Hopefully it would help the dev teams (and contributors) to identify bottlenecks and hopefully help fix some of the remaining of them... especially prior the next TB stable version...<br></div><div><br></div><div>In addition, I would like to encourage again all the dev teams (developers and contributors) to test features and code they design with very large data sets, that may help identify perf issues before they even land in a beta or stable version.</div><div><br></div><div>On another hand, if you could advise also how we can help from our end, how to best and better report performance issues encountered with steps and details for the common of mortal to follow, in a way that would be useful to developers and contributors, that may also help the overall project going in the right direction in term of performance... please do let us know. <br><br>Would there be already some resource available on the matter you could recommend?<br>Is recording a TB perf profil published and shared via <a href="https://profiler.firefox.com/">https://profiler.firefox.com/</a> the best way?</div><div><br></div><div>Thanks to all developers and contributors who may understand my point and are already contributing towards better performance in TB. If you can advise from your experience how we can better help, let us know as well.</div><div><br></div><div>I am just dreaming of the time (that will come) where TB would be fast and reliable at all time... from start-up to exit (without crashing at all)!</div><div><br></div><div>Regards,</div><div>Richard</div><div><br></div><div><br></div><div><br></div></div></div>