Re: Thunderbird is still using two MIME decoders, jsmime and
On 7/12/2016 2:43 AM, Jörg Knobloch wrote:
> I don't know why the last call site wasn't changed over, maybe is was
> left out deliberately. The only reason I could think of would be a
> Gecko's main thread; that was the issue why Outlook import doesn't
> work any more since jsmime was introduced.
The main reason was because the that last usage was "internal" to
libmime. I remembered there being something in relation to RFC 2231
decoding, but a closer look suggests that my memory is fallible. It was
deliberate but also justified in part that libmime was going to die
before too long, which has obviously not turned out to be the case. :-(
There's no terribly good reason to not switch that over (except for
Thunderbird and DXR developer
Source code archæologist
Re: Thunderbird is still using two MIME decoders, jsmime and Core::Network - Why?
On 2017/08/07 7:35, Jörg Knobloch wrote:
> On 14/07/2016 17:53, Joshua Cranmer 🐧 wrote:
>> There's no terribly good reason to not switch that over (*except for
>> perhaps perf*).
> To continue a discussion from July 2016:
> It turns out that for an attachment with 300.000 lines of base64, the
> header(!!) decoder is called 600.000 on the filename. There we notice
> that XPCOM + JS is somewhat slower than C++.
> Anyway, I reduced the calls to just two ;-)
It seems that there are other performance issues in TB, which I noticed
during debugging such as scanning message file and rebuilding database
THREE times after a compaction (I can live with two, but three is a