Invitation for technical discussion on next-generation Thunderbird

Ben Bucksch ben.bucksch at beonex.com
Mon Apr 24 15:15:45 UTC 2017


Gervase Markham wrote on 24.04.2017 16:54:
> I guess it might be possible to have all the metadata in memory to
> populate the tree, but not the message bodies? So whenever you load a
> message, that's when the async DB hit happens?

Yes, of course. We'd load only the headers, specifically the headers 
that are displayed. IMAP allows to fetch only selected headers, and any 
local DB should allow the same. We probably do need a DB, to avoid 
reading the whole mbox every time.

Personally, I don't see a problem of keeping headers of the currently 
opened folder in RAM. That's what 
http://benbucksch.github.io/trex/fastlist-test.html does (admittedly 
with 4 headers only), and it's blazingly fast. You can load a few 
hundred thousand mails (up to 1 million) without problem.

>
>> I think 1 million emails in a folder are an edge case. We should not
>> redesign everything for edge cases, as that will have costs in design
>> and implementation time, and might cause other disadvantages.
> What size of folder do you think we should have performance targets for?

I do not think folders with 1 million emails are common among normal, 
non-geek users, so it's not a case we should design for. Esp. if such a 
design creates other tradeoffs that regress the common case.

I think 10000 (normal user) to 100000 emails is realistic. Specifically, 
I would want a folder with 10000 emails to load in 100ms, a folder with 
100000 mails in 1 second, and a folder with 1 million emails may take 10 
seconds. That's my upper boundary. I'm not saying it will be that slow. 
I hope we will be much faster than that.

As the test above shows, the UI and RAM are not the primary problem.

Ben


More information about the tb-planning mailing list