Little Vulpix

I am very happy that you have extended the maximum dictionary size! With it though, I have one "feature request" or feature for consideration, which I think none of the other compression software has, that would be quite awesome to have. In short - ability to "hibernate" compression progress. Being able to pause compression, store current progress (the in-memory dictionary + current progress) to some temporary file and then resume. The reason is simple - using the best compression settings can result...

I can test this on my threadripper (1950x 128gb ram), however I would like to understand first; does this mean that when compressing, I was previously only able to select 3 threads max (otherwise it would cause compression ratio decrease), and now I can select (up to 64) without sacrificing compression ratio? Somehow I find that hard to believe because that would be amazing if it were true!

Aha! Yes I am! It is also a newly enabled option that I enabled along with the memory encryption. I didn't think of that. Indeed, I use secure desktop. It would also explain why it only happens for the instance of veracrypt that you used to mount the actual volume - because that is the only time a secure desktop password entry pops up. If you just launch veracrypt with the thread mounted, it no longer occurs. I have downloaded, installed and tested a mount with the beta6 veracrypt and can confirm...

I'd just like to say that the issue never came back (while at this point it would definitely have re-manifested). The last thing I could think of was that it had to do with the instance of veracrypt mounting the container (or in my case a partition), because this latest version I've tried, I never mounted it. I just exited the previous one and put the new exe in place, while the partition was already mounted. But nope, I tried dismounting and remounting (after also restarting the new version to make...

I'd just like to say that the issue never came back (while at this point it would definitely have re-manifested). The last thing I could think of was that it had to do with the instance of veracrypt mounting the container (or in my case a partition), because this latest version I've tried, I never mounted it. I just exited the previous one and put the new exe in place, while the partition was already mounted. But nope, I tried dismounting and remounting (after also restarting the new version to make...

I'd just like to say that the issue never came back (while at this point it would definitely have re-manifested). The last thing I could think of was that it had to do with the instance of veracrypt mounting the container (or in my case a partition), because this latest version I've tried, I never mounted it. I just exited the previous one and put the new exe in place. But nope, I tried dismounting and remounting (after also restarting the new version to make sure it is still launched with the new...

I don't know what changes you made but the second binary I got and am using right now is behaving just fine. No extra cpu usage at all. Only when I open the program and even then it's like 1-2% max. I launched it with the switch like before. Maybe it has to do with the fact I have exited the process previously without dismounting (to use the new veracrypt process) ? I don't know. I will update this if the behavior resurfaces after a reboot.

It is quite strange indeed. I tried the new version of veracrypt and well it's working right now, no cpu utilization (much like the previous time I tried - with the previous binary. I launched it with the switch again. Just to be sure, there is no reason for veracrypt exe process itself to be consuming CPU, right? All of the system utilization should come from the on-the-fly driver correct? (I mean, assuming all of the mounting etc is already done) Also, no, the favourite is not mounted automatically,...