• Registered: 2008-05-24
  • Posts: 35

Topic: Why is chumbyflashplay such a CPU hog ?

Playing from /mnt/usb using 'My Music Files' top shows:

Mem: 60204K used, 1744K free, 0K shrd, 884K buff, 34576K cached
Load average: 3.10 2.91 2.84
  PID USER     STATUS   RSS    VSZ  PPID %CPU %MEM COMMAND
12873 root     RW     13888  34576 12811 45.9 22.3 chumbyflashplay
12852 root     SW      3268   6236     1  6.6  5.2 btplayd

strace shows tons of 4 byte reads from /dev/timerm

read(9, "(\227\276|"..., 4096)          = 4 <0.000620>
read(9, ")\227\276|"..., 4096)          = 4 <0.000150>
read(9, "*\227\276|"..., 4096)          = 4 <0.000180>
read(9, "+\227\276|"..., 4096)          = 4 <0.000150>
read(9, ",\227\276|"..., 4096)          = 4 <0.000150>
read(9, "-\227\276|"..., 4096)          = 4 <0.000150>
read(9, ".\227\276|"..., 4096)          = 4 <0.000150>
read(9, "/\227\276|"..., 4096)          = 4 <0.000150>
read(9, "0\227\276|"..., 4096)          = 4 <0.000150>
read(9, "1\227\276|"..., 4096)          = 4 <0.000150>
read(9, "=\227\276|"..., 4096)          = 4 <0.000150>
read(9, ">\227\276|"..., 4096)          = 4 <0.000180>
read(9, "?\227\276|"..., 4096)          = 4 <0.000150>
read(9, "@\227\276|"..., 4096)          = 4 <0.000180>
read(9, "A\227\276|"..., 4096)          = 4 <0.000210>

Is this really necessary ?

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,209

Re: Why is chumbyflashplay such a CPU hog ?

Yes, the Flash Player reads /dev/timerm *very* frequently - it's the master clock for all of the animation timing.

At any given moment, the Flash Player is actually playing two Flash movies at the same time - the Control Panel (what you see when you press the top button) and whatever the current widget is that's playing, which may vary in load.  You may find that it uses far less or far more CPU depending upon the current widget and what the Control Panel might be doing at any given time.  I have seen some widgets take up 100% CPU.

Given that the system was more or less designed to play Flash movies, the system was spec'd to do that.  By today's standards, it's a pretty low powered device - in this case, a 320MHz ARMv5.

Duane's Website

  • Registered: 2008-05-24
  • Posts: 35

Re: Why is chumbyflashplay such a CPU hog ?

So it seems the 'My Music Files' widget puts an unreasonable load. Wonder who the author of the widget is ;-)

  • From: Australia
  • Registered: 2009-03-19
  • Posts: 505

Re: Why is chumbyflashplay such a CPU hog ?

But is it an unreasonable load?
If what the Chumby mainly does is play Flash movies, and if there is a limit to the number of other processes it will be asked to run simultaneously with these Flash movies, then why is using a lot of CPU bad? Wouldn't an efficient design utilise most of the available CPU capacity most of the time to run Flash movies?
I don't know much about these things, so I am asking from a genuine spirit of enquiry.

  • Duane
  • Duane
  • Blue Octy
  • Offline
  • From: San Diego, CA
  • Registered: 2006-08-24
  • Posts: 8,209

Re: Why is chumbyflashplay such a CPU hog ?

"My Music Files" may indeed be less efficient than it could be - I'll take a look.  What it does is constantly monitor the state of the music player on a periodic basis, it's possible it's doing that more frequently than necessary.

As steelpaw pointed out, we initially decided what the device was to do, and we picked the "best" processor for that requirement.  We could have spent more money for a more powerful processor (although there weren't that many other acceptable options at the time), but it would have been mostly wasted CPU cycles.  There were actually several different ARM SOCs under consideration at the time, the Freescale part was ultimately chosen because it was the most friendly to developers, and we got excellent support from Freescale.  Even then, there were still some subsystems that remained proprietary - Jazelle and eMMA - that we were not able to use.

The original prototype device (aka Foo/Katamari) was designed around FlashLite 2 - while we were designing the production device, what is now the "classic", we received the FlashLite 3 codebase from Adobe, which supported Flash Video, as long as the video used what was at the time a mobile-friendly profile.  We changed the design accordingly, mostly adding RAM.

Duane's Website