FF-hashdrop: low GUI priority

New in Version 0.1.2 is the ability to reduce the overhead which involves updating the gui (even without enabling this, the current GUI is update only every second and is no where near actual and accurate info - doing this would grossly eliminate the benefit of massive multithreading because you will need to serialized threads upon the display of gui information, if you want actual and correct information). The following discussion will show you the side effects, if you enable low GUI priority.

If you enable the check box "low GUI priority" in the lower right of the main window, you are disabling some internal routines, which made sure, that the gui stays always responsive, no matter how many threads are working in the background (current limit of threads is 512).

With an increasing number, the mac os x scheduler will try to distribute the cpu load evenly to all thread and this can ultimately mean, that you get not enough CPU for the main thread. This will result in a beach ball shown when you hover with your mouse over the application window.

Another issue can show up, if you are starting massively parallel (e.g. dropping the first level of subfolders from root of you entire file system):

The IO system will be stressed to the max, because after a few millsecs the first hash calculation threads are spawned and beginning to read from scanned files while the file scanner threads continue to descend the file tree, which spawning more calculating threads (reading more files) and so on.

This will put a serious load on your mac (both: CPU and IO), I have tried it on a iMac with 4 cores (only 200,000 files, file system contains a magnitude of that) and it is very serious stuff (all cores got up nearly 100% all time and you will hear you hard drive working...)