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