Leaderboard

No, but Repaint() is. In any case, depending on what the rest of your loop is doing, it may be worthwhile to move the logic into a worker thread, and then have that post updates to the UI thread when it wants to display something.

That's another reason why precompiled binaries are bad - if I had to guess I would say they are compiled for CPUs that support AVX which Nehalem did not have.

I doubt it. The bottleneck is the flash memory not the CPU This shouldn't happen. Probably OS has the option to set file size at start? This will remove file growth at every write. Anyway are you writing blocks or byte by byte? But the app won't do exactly what it claims to do. Data remnants will survive There's almost nothing "basic" in this world 🙂 even with steel anvil there's hundreds of hidden nuances to consider

You should probably review the NIST guidelines, no need to randomize the data, just fill it with 0 & 1. NIST uses the word pseudorandom a lot. Good summary: https://www.bitraser.com/article/use-nist-hard-drive-erasure.php Reference: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf Writing some strings in parallel might be a lot faster, I believe you have 8 channels on most controllers, so you can probably get 4-5 writes in parallel. This is only true if you write sector by sector, the OS controls where that file is placed. You would have to write 1 file the size of the free space to make that true in your scenario.

First of there is no 10.5 - I assume you meant 11. That's like the mother of pointless benchmarks. We know that default MM is prone to problems with heavy multithreading. Test with FastMM5 because that has addressed that issue. For using TBB, I think it was mentioned in another thread that also the memory footprint should be considered. Part of the improvement might come from the better system routines such as Move (FillChar has already been improved in 11.1) - I have been working on an improved version but I am afraid we will not get it before Delphi 12. Also - I think I mentioned this before: in the age of supply chain attacks and malicious code being distributed via open source platforms, I would be very careful about using some binaries. You mentioned before how you compiled them: why are you reluctant to post the code on GitHub so everyone can compile it themselves?

That is actually incorrect in the case of TIniFile. Internally, it uses the Win32 PrivateProfile API, and if you don't specify a full path then it will use the Windows folder, not the calling process' working directory: This is not the case with TMemIniFile. Agreed.