David Coker wrote:
Using a combination of visual feedback in the way of changing the
cursor to "watch", a status area to display progress and selective use
of wait statements, this little bugger is now as responsive and well
mannered as anything that runs on the machine. CPU rate is down below
50% even for the largest data thrown at it. The sacrifice here is in
the overall processing time, but it's still very acceptable now that
other work can be done during processing.
Once I have had time to play with the routines and methods a little
more, I'll try to put together a sample stack showing different ways
to accomplish this. Might help the next guy running into similar
difficulties. :)
Good work, David.
Do you use and progress bars? If so, I've found them very
cycle-consuming, and I tend to update them infrequently now when I'm
working with large data sets.
So instead of doing something like this:
put 0 into i
repeat for each line tLine in tData
add 1 to i
set the thumbpos of scrollbar "progress" to i
...
end repeat
Now I use the mod operator to reduce the number of times the progress
bar is updated:
put 0 into i
repeat for each line tLine in tData
add 1 to i
if (i mod 100 = 0) then
set the thumbpos of scrollbar "progress" to i
end if
...
end repeat
When I made that one change to WebMerge a while back, I got an overall
50% performance boost.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
