many segment-oriented function

Case number:699969-2004585
Opened by:LociOiling
Opened on:Thursday, December 21, 2017 - 02:03
Last modified:Thursday, December 21, 2017 - 02:25
(Thu, 12/21/2017 - 02:03  |  1 comment)

LociOiling's picture
User offline. Last seen 2 hours 29 min ago. Offline
Joined: 12/27/2012
Groups: Beta Folders

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

lockeds = {}
for ii = 1, structure.GetCount () do
    lockeds [ #lockeds + 1 ] = structure.IsLocked ( ii )

saves the locked status of each segment in a Lua table, and lets your replace this code:

  if structure.IsLocked ( seg1 ) then

with this:

  if lockeds [ seg1 ] then

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.


Developed by: UW Center for Game Science, UW Institute for Protein Design, Northeastern University, Vanderbilt University Meiler Lab, UC Davis
Supported by: DARPA, NSF, NIH, HHMI, Microsoft, Adobe, RosettaCommons