5 ms·

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

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.

Ono-Sendai 3y ago
Yeah I get this pause while writing emails too. Very annoying. Maybe it's a garbage collection pause?
- mcny 3y ago
  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?
  - j16sdiz 3y ago
    I thought it was the mbox storage format. Adding a label or mark something as read need rewriting the file.
  - Ono-Sendai 3y ago
    Haven't tried with a new installation. I have quite a few emails.
- kevincox 3y ago
  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.
KRAKRISMOTT 3y ago
> 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.
qzw 3y ago
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.
- ziml77 3y ago
  Or replace Defender with a faster AV product. Defender has always been massively impactful on file operations.
- tlamponi 3y ago
  No, I'm using Debian Linux (where it worked well >> 5 years or so) – still thanks for the tip.
ziml77 3y ago
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.
naasking 3y ago
> 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.
- tlamponi 3y ago
  > 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.
  - tentacleuno 3y ago
    Doesn't JavaScript's Atomics API provide synchronisation primitives?

Ono-Sendai 3y ago

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

mcny 3y ago
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?
- j16sdiz 3y ago
  I thought it was the mbox storage format. Adding a label or mark something as read need rewriting the file.
- Ono-Sendai 3y ago
  Haven't tried with a new installation. I have quite a few emails.
kevincox 3y ago
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.

KRAKRISMOTT 3y ago

> 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.

qzw 3y ago

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.

ziml77 3y ago
Or replace Defender with a faster AV product. Defender has always been massively impactful on file operations.
tlamponi 3y ago
No, I'm using Debian Linux (where it worked well >> 5 years or so) – still thanks for the tip.

ziml77 3y ago

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.

naasking 3y ago

> 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.

tlamponi 3y ago
> 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.
- tentacleuno 3y ago
  Doesn't JavaScript's Atomics API provide synchronisation primitives?