<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 18-07-2019 18:40, Wayne Mery wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d0d61c80-ae2b-9060-5a81-4d1170111911@lehigh.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 7/18/2019 7:05 AM, Magnus Melin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:30031e0b-9f31-cccc-e94c-9edb09f148be@iki.fi">
<p>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.</p>
</blockquote>
<p>Why should tests block fixing bugs, which in some cases prevent
users from using Calendar, or keep users on an older version
Thunderbird/Calendar?</p>
</blockquote>
<p>They don't need to wait, I'm just saying that with tests it's
much more easy to see if the changes have the desired effect.</p>
<blockquote type="cite"
cite="mid:d0d61c80-ae2b-9060-5a81-4d1170111911@lehigh.edu">
<p> And are you suggesting we need to make the <a
moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=978570">switch
to ical.js</a> before making further tweaks?<br>
</p>
</blockquote>
<p>Not really. We want to make ical.js performant enough to replace
libical by 76 (preffed on by default) and drop libical shortly
after. But to make sure it actually is performant enough, tests
would be helpful.<br>
</p>
<blockquote type="cite"
cite="mid:d0d61c80-ae2b-9060-5a81-4d1170111911@lehigh.edu">
<blockquote type="cite"
cite="mid:30031e0b-9f31-cccc-e94c-9edb09f148be@iki.fi">
<p>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.</p>
</blockquote>
<p>You're not suggesting not waiting 1-2 ESR to fix perf
improvements that don't require multiprocess, correct?<br>
</p>
</blockquote>
<p>All improvements are of course welcome to land as soon as someone
comes up with them.<br>
</p>
<p> -Magnus<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>