Quote:
Some things that came to my mind after some weeks of using:
- shorter save times
Right now I have to manually copy the current P value into the config file - at least on that computers that don't hibernate...
Alternatively a key combination to write the current status to file and exit - if implementing this handler doesn't affect performance.
OK, that might be possible.
Quote:
- option to fine-tune alpha setting
I guess here one can squeeze out an additional percent or two. According to my observations, the optimal value depends on the system architecture and the search range seems to have a slight influence, too.
Ah, there is a -a=<value> command line switch to change the alpha. 2.5 is used by default. Ah, but that doesn't seem to work...
Quote:
- fewer status outputs (optional)
As speed is really adorable, I get 1.5 status updates per second on some systems. I'm not sure if there will be a performance improvement when the output rate is reduced, but I guess it's worth a try.
Hardly *any* of the time is spent doing IO. I could reduce it, but the net effect would be about a 0.001% gain.
Quote:
- output of "clean" factor file
When computation of the set rate is completed, the program could create a new file and paste the factors of the config file. Maybe an overwrite protection is ideal to prevent overwriting of factor files not yet submitted...
There is another approach that I could use, but backward-compatibility would be a problem. Are you not using the small utility that was posted up here to clean the file before submitting it?
Regards,
Paul.