Comment by yetanother12345 | Hacker News Reader

Comment by yetanother12345 | Hacker News Reader

yetanother12345

> Our fastest ... ever

Last time I installed Thunderbird seems to have been in the 00's sometime[0]. Since then I have used the same install, only updating it, and moving/cloning to other units.

Back then PCs were s-l-o-w but Thunderbird was _fast_. Moreso than Outlook/Outlook Express in startup as well as operation. Then, speed deteriorated bit by bit over the years. Due to feature creep, I suppose (in other news; also UX in several subtle ways that all add up).

I do not believe that the claim of "Fastest ... ever" is credible, and I have reason to believe that speed on an 13yo X86 unit still running 32bit[1] will not be impressive. Still, if speed is improved even slightly I'd welcome that.

[0] Datestamp of earliest email in a random folder is December of 1999 - 23 years ago. But then the earliest emails were imported from another email client into Thunderbird. In any case I started using Thunderbird as a very early adopter, mostly due to their very convincing Firebird product (I was in Tech then, too).

[1] The unit I prefer using for anything that does not require Windows or other ressource hogs (eg. browsing like now). Yes it's _that_ old. It's Linux, so no problem.

Yeah, I'm still disappointed that they swapped out lots of their C++ implementation with JavaScript. While I definitively think that the devs were qualified to determine that their C++ code base was a too big maintenance burden, I just would have hoped that they went for Rust as replacement, after all Thunderbird shares code with Firefox and came from Mozilla, i.e. the company that gave rust the resources it needed to evolve and become stable to be a C++ replacement...

While JS engines are an engineering marvel, they just cannot compete with bare metal compiled code, and the JS single-thread model really doesn't help.

I suspect that this is one of the reasons that the input field used for composing a plain text message hangs up every 20s - one minute as the backend has to do some IO or the like, even if the input field could be completely independent (e.g., I never see this behavior in Firefox, with much more tabs open and stuff happening in the background).

It might have also other reasons, and it might also be solvable with their JS stack, but what I know for sure is that the effects are real, and I face several frustrating moments a day when my email editor just freezes for ~10s and that this behavior was not existing a few years ago. I even upgraded to a quite powerful workstation (a TLC NVMe over PCIe 4.0, 128 GiB of DDR5 memory, i7-12700K CPU), so yeah not signing off on the "fastest ever" either, that's rather a slap in the face of all power users.

Yeah I get this pause while writing emails too. Very annoying. Maybe it's a garbage collection pause?

I thought it was just me because my profile folder is now ~100GB. Are you able to reproduce this even with a new installation and new email account with no emails?

I thought it was the mbox storage format. Adding a label or mark something as read need rewriting the file.

Haven't tried with a new installation. I have quite a few emails.

I used to get this a lot but haven't seen it in a year or two. But I have switched to the message-per file storage format, so that may be part of the issue.

I have 366k messages, but all in one folder and used to see hangs even when that folder wasn't open (but it was being synchronized).

I still get hitches and sometimes crashes due to not responding for too long when navigating other things, but message composition seems fine now.

> the JS single-thread model really doesn't help.

I suspect that this is one of the reasons that the input field used for composing a plain text message hangs up every 20s - one minute as the backend has to do some IO or the like, even if the input field could be completely independent (e.g., I never see this behavior in Firefox, with much more tabs open and stuff happening in the background)

That's just poor engineering and architecture, not an inherent limitation of JS. Modern JS supports multithreading through WebWorkers, see VS code as an example of what a proper editor should be. V8 is an insanely performant engine.

If you're on Windows and use the built-in Windows Defender (or whatever it's called now), try excluding your Thunderbird mail folders from scanning. The AV locks the files while scanning and that freezes TB.

Or replace Defender with a faster AV product. Defender has always been massively impactful on file operations.

No, I'm using Debian Linux (where it worked well >> 5 years or so) – still thanks for the tip.

Javascript's single thread is an event loop. If the code is written correctly, it should not be holding anything else up to do I/O. That can be dispatched to run asynchronously, and when the data is ready the event loop will call back into the code that was waiting for the response. Also, modern JS engines do support spawning threads. But even if they didn't natively, the Thunderbird devs could have exposed APIs to JS code that allow it.

> While JS engines are an engineering marvel, they just cannot compete with bare metal compiled code, and the JS single-thread model really doesn't help.

This has nothing to do with it. When was the last time your browser locked up in Google Docs which is also primarily JS-driven?

Event loops are great and solve all kinds of concurrency hazards. If you need more parallelism, then spin off another event loop to do separate processing tasks. There's no reason each email composition window can't be its own event loop, for instance.

> This has nothing to do with it. When was the last time your browser locked up in Google Docs which is also primarily JS-driven?

I don't use Google Docs, but I often get slow JS-ridden sites, also I never said this is the sole reason it's slow, at the end I even mentioned that it can be fixed with JS too – still rust is 10x faster and more efficient (better power usage on laptops), naturally one can code in both language such that it sucks independently – still, rust makes it harder to hold it wrong.

> There's no reason each email composition window can't be its own event loop, for instance.

Yeah, never said the contrary but a) still will be faster if done in rust or something like that (I use both JS and rust a lot, so I got at least _some_ experience with those different ecosystems) and b) it doesn't help if you do IO and hang in kernel D state then the whole thread hangs, including any IO loop. Rust's prime async framework tokio has solutions for that, being a work-stealing executor it can detect this from another thread and move unrelated futures to other threads and continue execution there. Sure, maybe one can shoestring that together with JS, but it's not making things more maintainable (as was the original goal), as JS gives you no access/synchronisation guarantees.

Doesn't JavaScript's Atomics API provide synchronisation primitives?

>Last time I installed Thunderbird was in December of 1999 - 23 years ago

Surely that can't be right unless you had a time machine, as it was released in 2004, being based on Phoenix/Firefox.

I've always thought of a time machine as being capable of traversing time but not rearranging it.

It existed before that and was called Minotaur, which was a work to separate the mail client from the Mozilla suite. Thunderbird wasn't written from scratch from Phoenix or firebird. But it benefited of all the improvements made to common code used by Phoenix if memory serves right.

The pre-1.0 releases were functional (they were derived from the Mozilla App Suite) and relatively popular. I used Thunderbird 0.2, which Wikipedia says would have been in 2003.

Funny, all this time ago and I remember the naming controversy with Firebird the database (which I've also used, we were using Interbase, we were a Delphi shop back then).

I LOVE Thunderbird - never even left. I also use Tutanota, which has its own desktop client; very nice for folks who don't want to take care of the encryption themselves.

Thank you for the tip! Tutanota looks great!

I assumed they mean fast as in, "shortest delay since the previous major release".

It's fast when it doesn't crash on a big local mailbox. Otherwise it's fast to crash and presents you repeatedly with the choices to wait or kill the app.

Seeing as this looks like the finally moved over the Firefox Quantum codebase, it will possibly be faster provided you have the memory to support it.

Like FF Quantum, it was definitely faster than the previous version but the memory usage jumped big time as they went down the Chromium route of speed optimization.

I sense we may end up with a fork of this just like Firefox did with Pale Moon.

Firefox also started moving away from a shared memory model towards sandboxed tabs during that period, which had an effect on memory consumption.

I hadn't looked at Thunderbird since about that time. I trashed it back then because there was no way to export your filters, in order to copy them to other computers... an absurd deal-breaker. Has that been resolved, by the way?

A few years ago I got my parents new computers. Sadly they are Windows machines, since that's what they're used to. After finding Microsoft's E-mail client to be monumentally defective trash, I installed Thunderbird for them. What a pleasant surprise. It worked well, looked good, and it downloaded all 15,000+ messages from each of their AOL accounts. Yep, AOL.

> I hadn't looked at Thunderbird since about that time. I trashed it back then because there was no way to export your filters, in order to copy them to other computers... an absurd deal-breaker. Has that been resolved, by the way?

I don't think it has been, but I'm hopeful that the upcoming Thunderbird Sync feature will support syncing filters. I know they are only focused on syncing email account credentials right now, but that's honestly the last thing I care about syncing. More important are all the other little settings, such as filters, that are a huge pain to remember to manually change on all my computers.

Thanks for the reply. It's aggravating that this remains unaddressed. I don't even care about "syncing." All we need is to be able to export them to a file and then import them to another installation.

It may not be popular to say this about free software, but WTF? That is simply stupid.

And the apologist brigade downvotes uncomfortable facts yet again.

Your lack of desire for syncing is neither uncomfortable nor a fact.

The filter configuration for an account is in a text file in your profile, in a location like ImapMail/imap.example.org/msgFilterRules.dat

Copying these files around and editing them by hand works fine.

Thanks for the info. That's pretty clumsy, when an import and export function would seemingly be straightforward to implement.

Thunderbird (like Firefox) has a profile folder. If you copy that to another machine everything should be the same on that new machine. I have been doing this since probably 2009 and I make use of filters.

It's absurd that this function (filter import/export) hasn't been built into the application. Why should people have to scrounge around in user directories (after having to look up the appropriate location for whatever platforms they're using)?

Also, can you have global filters? I don't want filters per E-mail account.

Reply on news.ycombinator.com