Marek K. ZBOROWSKI wrote: This changed nothing, latest v11.x with indexing off still makes my laptop unusable despite it is AMD Ryzen 7 5825U with SSD. No pop3, just imap and TB! is a real crap now.
Whoa. Are you sure the indexing is really turned off? The registry key has value 1?
If it's not the indexing, do you have any idea what else it could be? You could try setting up TB not to immediately connect to the IMAP servers (Account -> Properties -> Mail management). If throttling starts when communication with an IMAP server starts, the source of the problem could be there somewhere.
Miloš Radovanović wrote: Whoa. Are you sure the indexing is really turned off? The registry key has value 1?
Yes, I set the key before running TB! After starting TB! Windows becomes almost unresponsive - starting any other app lasts forever, and then even closing TB! does not help and all you can do is restarting Windows. This happens every time with v11.x, but no with v10.x.
wrote: Whoa. Are you sure the indexing is really turned off? The registry key has value 1?
Yes, I set the key before running TB! After starting TB! Windows becomes almost unresponsive - starting any other app lasts forever, and then even closing TB! does not help and all you can do is restarting Windows. This happens every time with v11.x, but no with v10.x.
I am in the same situation and it is not a problem of lack of resources. I have an I7 with 16 Gb of ram and SSD.I wrote to Rilabs and their response was...
"We have not received similar reports from other users so far, and could not reproduce the issue on our computers, so the only solution is to follow the steps once again to re-install The Bat! completely (make sure there is no process remained in the Task Manager)."
I put the link to this thread and their response was...
"Thank you, we do not monitor the forum, that is why were not aware of the issue. We would need the users to contact us in the Support section and provide details."
Marek K. ZBOROWSKI wrote: Yes, I set the key before running TB! After starting TB! Windows becomes almost unresponsive - starting any other app lasts forever, and then even closing TB! does not help and all you can do is restarting Windows. This happens every time with v11.x, but no with v10.x.
Have you tried running Windows in safe mode? It could be a bad interaction with an external program like an antivirus. Or a buggy interaction with the IMAP mail server. Anyway, if TB does not throttle anything when run in safe mode without internet access, is is probably one of those two. If it does throttle in safe mode with internet access, it is probably the latter. If it does not throttle in safe mode with internet access, it is probably the former.
Leopoldo Garcia wrote: "Thank you, we do not monitor the forum, that is why were not aware of the issue. We would need the users to contact us in the Support section and provide details."
They are aware of the indexing issues now, I have an ongoing ticket, too. Let's hope they don't double down on the indexing. I'll soon finish some more detailed testing, but so far it seems that the way SQLite is used is inherently bad.
wrote: Yes, I set the key before running TB! After starting TB! Windows becomes almost unresponsive - starting any other app lasts forever, and then even closing TB! does not help and all you can do is restarting Windows. This happens every time with v11.x, but no with v10.x.
Have you tried running Windows in safe mode? It could be a bad interaction with an external program like an antivirus. Or a buggy interaction with the IMAP mail server. Anyway, if TB does not throttle anything when run in safe mode without internet access, is is probably one of those two. If it does throttle in safe mode with internet access, it is probably the latter. If it does not throttle in safe mode with internet access, it is probably the former.
If it was the fault of the antivirus, closing the application would stop the problem, by the way, I've tried running TB! without antivirus and the problem continued. The same would be true if it was the mail server - but closing the program does not speed up the operating system again, and only restart does. Anyway, why doesn't v10.x cause this problems? It must be something that was implemented in the latest v11. Probably this is caused by some kind of interaction with Windows itself.
Dear all, here are the results and observations of the extended tests I promised. I sent them to support as well.
I performed some tests with SQLite index formation on my message base, starting with the complete one, gradually reducing its size and compacting folders after each reduction. The results are in the linked table, together with some general observations:
Configuration: Lenovo ThinkPad laptop, i7 CPU, 16 GB RAM, 512 GB SSD. Windows 10 Pro 64-bit with all the latest updates, The Bat! v11.0.3.1. POP3 account with all messages downloaded.
I was hoping that at some point I would reach a message base size where indexing performance becomes drastically better, suggesting that an increase in some RAM buffer/cache size for SQLite could make things right for larger message bases, but alas this wasn't the case. The performance scales linearly with message base size. Some additional notes are in the attached table.
"First run" refers to building the complete index from scratch after deleting the index.db file. "Second run" refers to running The Bat! again, when index.db is updated. No manipulation is done to messages between runs. "GB written to disk" was measured using CrystalDiskInfo.
In my opinion, the SQLite indexing performance is subpar for users with larger message bases (they don't need to be very large) even on fast computers. For users with HDDs instead of SSDs, the indexing throttles system performance drastically.
For comparison, combining messages from multiple folders into a single virtual folder or message list tab with 94000 messages viewed using a threaded view mode takes 4-5 seconds on the same system using the old The Bat! indexes.
Well, so far there is no update to solve the problems we reported, but.... First I observed and reported the problem using a Lenovo brand laptop. I recently purchased a new laptop and decided to see how TB! would behave on it. It turned out that after installation there were no problems. The new computer has an Intel processor, but to rule that out I installed TB! on another computer with an AMD processor (Asus) - here, too, there were no problems.
In this situation, I came to believe that the problem may be Lenovo software - more specifically, Lenovo Vantage Service.
Running TB! version 11.x with LVS enabled causes nightmarish slowdown of the computer I reported in this thread earlier, and what bothers me the Lenovo Vantage program itself, when trying to run with TB! reports problems with Webview2 operation.
After disabling LVS auto-boot along with Windows startup - TB! works properly and does not cause the computer to slow down - at least so far. I'll be willing to observe this further today.
Could someone please confirm my observation and conclusion? Thanks.
Marek K. ZBOROWSKI wrote: After disabling LVS auto-boot along with Windows startup - TB! works properly and does not cause the computer to slow down - at least so far. I'll be willing to observe this further today.Could someone please confirm my observation and conclusion? Thanks.
My Lenovo laptop does not run LVS. For good measure, I killed all Lenovo processes and tested again, same behavior.
To be clear, I was never experiencing slow-downs, just lots of activity that really should not be happening. LVS could be aggravating the problem, but I can't confirm that. The root of the problem, which is horribly inefficient SQLite indexing, remains.