many segment-oriented function
Case number: | 699969-2004585 |
Topic: | General |
Opened by: | LociOiling |
Status: | Open |
Type: | Suggestion |
Opened on: | Thursday, December 21, 2017 - 02:03 |
Last modified: | Thursday, December 21, 2017 - 02:25 |
»
02:32:06 GMT
|
||||||||||||||||||||
many segment-oriented function
»
|
| | ||||||||||||||||||
Oops, hit the wrong key.
Desired title: "many segment-oriented functions seem slow".
This one really is a suggestion to recipe writers, based on chat in #veteran with Susume and some other observations.
Most of Foldit functions which are indexed by segment seem very slow, even ones which return constant information, like structure.IsLocked.
I notice this effect for the aflatoxin puzzles in particular. The recipe "print protein" had some duplicated calls in its various phases, retrieving segment subscores and other information. Caching the subscores (print protein doesn't do anything to change the score) greatly improved performance.
(Compare the code for print protein 2.7 to print protein 2.6).
The same principle seems to apply to other functions. Adding this logic
saves the locked status of each segment in a Lua table, and lets your replace this code:
with this:
The table method seems to pay off very quickly, but I don't have any precise figures.
Susume has also noticed that many band functions seem similarly slow, slower than in previous releases. Again, caching results of "getter" functions may help improve performance. With this method, you can also update the saved values when you do a "set" call, which spares the overhead of another "get" call.