TB, Electrolysis & Quantum
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 , 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
> In any case, there is a large amount of work required in Lightning
> before we should consider enabling e10s just for these issues.
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
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 :
* 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