TB, Electrolysis & Quantum

Wayne Mery vseerror at lehigh.edu
Thu Dec 29 18:00:30 UTC 2016

On 12/29/2016 11:14 AM, Philipp Kewisch wrote:
> On 12/29/16 5:00 PM, Disaster Master wrote:
>> For example, there have been numerous issues with Lightning that will
>> bring all of Thunderbird to its knees, and apparently it is still a
>> problem even today where a large number of remote calendars are in use.
>> And yet another example is [Cal/Card]DAV. What happens when the remote
>> server is having problems?
> While I agree it would be great to put some of the processing into extra
> threads or processes, this is not immediately fixed by introducing
> multiprocess Thunderbird. There are some other issues that require
> attention related to data structures and storage, which may already fix
> the Lightning freezing with many events. It may also be sufficient to
> put some processing into workers (Threads) instead of using the e10s
> multiprocess model.

The same logic applies in non-calendar areas of Thunderbird, where 
architectural factors would prevent performance improvements despite 
enabling e10s [1], or be outright broken by e10s which would require big 
changes to fix.

> The only case where there may be an immediate benefit is putting the
> calendar views into a separate process if the bottleneck is indeed the
> display of the DOM. This could also be solved by simplifying the DOM or
> maybe using HTML instead of XUL. On the other hand, it may well be that
> the overhead of transferring the event data from the main process to the
> content process exceeds the benefit of enabling e10s for that part of
> calendar.
> In any case, there is a large amount of work required in Lightning
> before we should consider enabling e10s just for these issues.
> Philipp

Indeed. e10s sounds great in the abstract, but we're not living in the 
abstract world.  It took firefox multiple years of coordinated effort to 
get where it is today, and Thunderbird doesn't have those types of 
developer, QA and other resources.

And there there is addons.  I should think that would pretty much kill 
the e10s idea right there.

Even if we assume it was feasible in the near-term, is putting effort 
there the best allocation of resources?  Likely not, when:

a) There are so many other pressing functionality issues - which are 
born out by the ratio of such reports in bugzilla and in SUMO compared 
to performance issues.

b) The question of what long term technology/architecture to move to is 
still unresolved.

c) Significant, feasible performance gains are possible near term with 
far less work and risk (and in many cases requiring only "average" 
developer skills), which would benefit non-power users and users on less 
modern hardware.  A few examples [1]:

* Finishing maildir. Why: Help backup performance, message display and 
overall performance for antivirus vendors who after a decade still can't 
seem to coexist well with us. Bug 845952

* Stopword support (Gloda) Why: Help both indexing and search 
performance, plus reduce disk space.  Bug 681754

* Reenable HWA  Why: We know some users benefit (but we don't know to 
what extent). There are surely some remaining problems, and perhaps the 
core devs would fix them.  (We disabled it two years ago because many 
users where horribly impacted. But Firefox has made progress, so maybe 
today it wouldn't be so bad?) Bug 1195947

* Async folder open (Gloda)  Why: All folder opening happens on the 
UI/main thread. Linear impact for users with large folders.  Bug 551209

* Async folder open (Autosync) Why: All folder opening happens on the 
UI/main thread. Linear impact for users with large folders.  Bug 588952

* Slow disk I/O (pop)  Why: The best IO is the one that isn't done.  Bug 
1242046 (nearing completion)

More information about the tb-planning mailing list