Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jbrave
Channel Surfer

optimizing wait loop performance

Does anyone have a tip for best settings for smoothest loop performance? I currently am using msg=wait(125,port) so I can update my screen 4x per second. Was just playing with EULive and it seems to do some graphical multi-tasking and is a bit smoother when music is playing. Of course, it updates the screen much slower than I do.

Also any execution loop performance suggestions would be good. Has anyone done a test to see how many milliseconds various brightscript functions take to execute? A benchmarking test would be an interesting project, if anyone would like to collaborate on one, let me know.

- Joel
Screenshades: The first Screensaver for Roku2!
Musiclouds: The best free internet music, on your Roku!
Ouroborialis: Psychedelic Screensaver for Roku!
0 Kudos
3 REPLIES 3
kbenson
Visitor

Re: optimizing wait loop performance

"jbrave" wrote:
Does anyone have a tip for best settings for smoothest loop performance? I currently am using msg=wait(125,port) so I can update my screen 4x per second. Was just playing with EULive and it seems to do some graphical multi-tasking and is a bit smoother when music is playing. Of course, it updates the screen much slower than I do.


It really depends on your needs. Some components have methods to set messages to be set at specific intervals (e.g. every second of video played on roVideoScreen). Others require manual solutions like you are referring to. There can be a big difference in how you go about handling a loop that needs to do screen updates at specific intervals compared to a loop that just needs to update some data.


Also any execution loop performance suggestions would be good. Has anyone done a test to see how many milliseconds various brightscript functions take to execute? A benchmarking test would be an interesting project, if anyone would like to collaborate on one, let me know.


We've done quite a bit of performance tests, unfortunately they were all pretty informal and we didn't save any results. To do this in a reliable manner, we need a test suite that runs and reports times (for what it can, audio/video updates are hard to rack). Otherwise, it may be useless after the next version. We've kicked the idea around a bit... There's a LOT to be tested to get any sort of adequate coverage. Maybe if Roku has sets of tests they run, a portion could be open sourced so the developers could collaborate and we could work together on getting really good test coverage. I know a TAP class was something Geoff was looking at...
-- GandK Labs
Check out Reversi! in the channel store!
0 Kudos
jbrave
Channel Surfer

Re: optimizing wait loop performance

Well, I'm using a rather funky method to update the screen - popping an roOneLineDialog and immediately closing it, its fast enough that you don't see it, but I couldn't figure out any other way to force the graphics on an roPosterScreen to update immediately. When its running the response of the remote is noticably slow, especially when an audio file is queing.

As far as benchmarking, I would imagine part 1 of the problem would be to get an accurate measurement of the time.mark() command, so one could calculate the overhead of the test itself, then wrap each statement to be tested like:

time1.mark()
statement to be tested.
time2.mark()

result = time2 - time1

starting with simple things like integer assignment and moving up from there?

- Joel
Screenshades: The first Screensaver for Roku2!
Musiclouds: The best free internet music, on your Roku!
Ouroborialis: Psychedelic Screensaver for Roku!
0 Kudos
kbenson
Visitor

Re: optimizing wait loop performance

"jbrave" wrote:

As far as benchmarking, I would imagine part 1 of the problem would be to get an accurate measurement of the time.mark() command, so one could calculate the overhead of the test itself, then wrap each statement to be tested like:

time1.mark()
statement to be tested.
time2.mark()

result = time2 - time1

starting with simple things like integer assignment and moving up from there?


I have a feeling that most the built in parts of BrightScript will perform moderately well. I don't know enough about benchmarking a language to tell what's worth doing and what isn't, but that just means that before starting anything like this in earnest some research would definitely help.

It's worth noting that BrightScript's implementation suggests that they tried to sidestep most of the language performance optimization issues by using components written in C/C++ for performance (and ease of integrating shared libraries, I assume). For the most part this works wonderfully. Manually implementing any included component with BrightScript alone (if given the capabilities) would lead to a VERY slow display (graphics code generally has a lot of loops to twiddle all or a portion of the bits in the display buffer).

In some tests, BrightScript isn't slow at all. For example, it takes ~600-700 ms to assign a simple division to a variable 10k times, compared to ~16 ms in Perl on a 2.2 Core Duo system. Considering the difference in processors, processor extensions, language age and optimizations, I think ~40x reduction in speed for running something on the Roku is actually quite good, for the time being at least. Then again, returning that simple division from a function and assigning it to the variable the same number of times incurs only ~10% penalty in Perl, but a 5000% penalty in BrightScript. This is most likely due to Perl optimizations (such as inlining the function), but highlights that BrightScript probably has many avenues for optimization that haven't been followed, and nor have they been needed yet.

In truth, I haven't really encountered many spots where BrightScript itself was the bottleneck. The only one I can think of was when implementing CRC checks (see librokudev), and that was mitigated by just using the pre-cached CRC table and referring to it. Another spot that may become more painful in the future is doing operations on roByteArray objects. As it is now, copies of portions of a byte array could do with an interface method, as manually looping over larger byte arrays DOES get to be time consuming.

In the end I think it's probably better to spend our time writing code that actually accomplishes a task, rather than benchmarking for its own sake. I think Roku will be a lot more responsive to speeding up an operation in BrightScript when we can show that it's directly impacting something we are trying to accomplish. Until then, their resources are probably stretched too thin to do general optimization in BrightScript unless it's obvious and speeds up the whole language at once.
-- GandK Labs
Check out Reversi! in the channel store!
0 Kudos