Foldit causes a huge amount of disk I/O during a script by writing an undo file for every change the script makes to the protein - every rebuild, every shake or wiggle. Some scripts you want to be able to undo the last few moves when the script ends or when you stop it manually, but for most scripts you would never use undo to go back after the script has stopped. If you want to go back you would either use one of the restore-best commands, or load the quicksave slot where the script stores its current high score, or load a manual save from before the script.
I suggest adding a checkbox somewhere to indicate that you do not want undo data saved while a particular script is running. This would cause a reduction in disk I/O and likely improve game performance for people on older machines. I know the most common cause of poor performance on my 5-yr-old machine is when CPU use goes to zero as everything waits for disk I/O to catch up.
If this can't be implemented on a per-script or per-run basis, it could be a checkbox on the undo graph properties dialog that disables undo data during all scripts. All the best score saves and quicksaves would still be written as files during the script and could be used after the script stops to go back to a particular pose.
There is a lua function to prevent undo points from being pushed onto the undo graph. I've been meaning to add that to some of my scripts for a long time. Would using this function actually cut down on the disk IO or is it purely cosmetic?
Of course, the scripts which would be modified, which is a problem for lazy and absent authors like myself.
Please tell, what is the function? Even if I could only add it to DRW that would save thousands of file writes.
H'mmm brow42 is correct…the function is undo.SetUndo
http://foldit.wikia.com/wiki/Foldit_Lua_Functions#undo.SetUndo
Ignored up until now by every single recipe that I've looked at. It seems like recipes could turn off undo at the start and then turn it back on at the end. The turning it back on should be done in a cleanup routine to catch recipe crashes and cancels.
See http://fold.it/portal/recipe/101925 for an example of a cleanup routine, which works with the xpcall function.
[You do that undo, that you do so well…]
Loci
great suggestion. I'm not a coder, but you are correct that we'd likely just go to best slot in a recipe if backing up
Skippy
Susume, are you seeing a performance boost from undo.SetUndo?
Early testing here not seeing a significant difference. I have two versions of the same recipe with fixed random seed running on the same solution. One recipe has undo.SetUndo ( false ) at the top, the other doesn't. So far not seeing a difference between the two. (Which is actually a little odd, many recipes quickly diverge, even with same random seed.)
I found the somewhat terse announcement here: https://fold.it/portal/node/989977#comment-26179
It's not clear that undo.SetUndo ( false ) is "off", will try "true" as well.
Interesting to contemplate what happens if a recipe turns off undo and leaves it that way. There doesn't seem to be a way to turn it back in the foldit GUI.
undo.SetUndo(false) disables the writes to the undo graph and files. True re-enables them.
I don't know yet if I am seeing a script performance boost; I have not done side-by-side comparison. If your system is not I/O bound you would not expect a benefit, but my machine is often I/O bound.
I am not seeing as much decrease in system-wide disk activity as I expected. Prior to disabling foldit undo writes I would always see a lot of these in the top of the performance monitor list when the system was bogged down, so I blamed the traffic on foldit. With foldit traffic cut way down, I am still seeing the disk maxed out sometimes but it is from other, non-foldit files (I can't always tell what app it is from because so much of it is owned by "System"). Presumably foldit can do more processing before it has to wait for disk I/O, so these slowdowns caused by other processes should affect it less.
You have probably considered this already but Windows 7 does really improve after a clean install. Also it could be time for a really good clean and new thermal paste, overheating can cause this symptom as the device tries to cool itself and slows down.
wow thanks ! I'll try to implement this in my recipes asap !
