A point of reference

Magnus Melin mkmelin+mozilla at iki.fi
Thu Mar 8 08:15:25 UTC 2018

On 08-03-2018 06:58, Joshua Cranmer 🐧 wrote:
> It is not an easy task to swap out something as key as a database. Since an 
> email client is largely a view around a database with some backend tasks 
> manipulating it, the nature of that database will tend to dictate the API. 
> We've known for years that Mork is not capable of achieving the performance 
> endpoints that we want, but we can't easily change it to another database 
> because the API relies on key characteristics of Mork (e.g., sync access to 
> all objects once the database is opened).
> This is why I've harped on so much about achieving specific performance 
> endpoints. We know performance is an important feature for our users, and if 
> we're rewriting the database, it is dereliction of duty to not look towards 
> achieving that performance from day 1. This is why I advocate for 
> challenging performance metrics from the onset: if we can handle a million 
> message folder now, we have an API capable of achieving high performance on 
> more modest folders even as we load it down with more functionality over 
> subsequent iterations. We can no longer expect platforms to naturally 
> provide us with speedup to cover the extra load in the future.

The issue of performance need to be looked at on from a higher level too. Why 
are gmail able to handle loads of mails without hit? Because they do not load 
anything but details on 200 (is it?) messages at the time. If you want to 
load, or keep any kind of details whatsoever for millions of messages in 
memory it's always going to be a performance hit of some sort, independently 
of what language you write that in. The question is really how to load as 
little as possible, and what kind of compromise are we willing to do in the UI 
to accommodate that.


More information about the tb-planning mailing list