On 12/03/2011 05:24 PM, Yasha Karant wrote:
> On 12/01/2011 04:52 PM, g wrote:
>> On 12/02/2011 12:19 AM, Yasha Karant wrote:
>>> From the top command :
>>>
>>> 8587 ykarant 20 0 794m 449m 30m R 81.8 5.6 561:50.12
>>> plugin-containe
>>>
>>> with the 81.8 being %CPU composite usage on a modern quad-core X86-64
>>> machine.
>>>
>>> ps axw reveals:
>>>
>>> 8587 ? Sl 562:06 /usr/lib/firefox/plugin-container
>>> /usr/lib/flash-plugin/libflashplayer.so -greomni
>>> /usr/lib/firefox/omni.jar 13704 true plugin
>>>
>>> Does anyone understand why plugin-container for libflashplayer.so is
>>> such a CPU usage hog?
>>
>>
>> see this link for operation of plugin-container;
>>
>> http://kb.mozillazine.org/Plugin-container_and_out-of-process_plugins
>>
>> it is possible that if you have a lot of plugins, they are using up
>> memory, or just one is hogging memory.
>>
>> if you have multi java plugins, disable them one by one to see if hogging
>> and you could delete old ones.
>>
>> also, if you have plugins that you seldom use, disable them.
>>
>> another thing you can do is disable all add-ons to see how much memory
>> plugin-container is using.
>>
>> remember, you must restart firefox for changes to apply.
>>
>
> I apologize for being dense, but I do not understand your explanation.
> ps axw should display all instances of any process, as should top for
> those instances consuming significant resources. Thus, my machine
> appears to have had only one instance of the flash plugin. Or, do
> plugins have a means to avoid showing up as processes because of some
> internal threading mechanism or the like? Does top not accurately report
> the resource usage of plugin-container, flash, etc.?
>
> To any of those who are familiar with the source code and/or internal
> operation of the flash plugin, why is it such a resource hog? Is there
> any (perhaps lacking public documentation) parameter(s) that can be set
> to change this? E.g., have flash update an image at longer intervals for
> lower quality, but less resource use.
>
> Yasha Karant

This has been an eternal source of Old Guy VS New Kid arguments over the
benefits/demerits of Flash in general.

If you have lots of web pages open, each with a flash-enabled
advertisement banner open, then flashplayer will have a thread open
per-ad. These add up quickly, particularly on the more obnoxious web
pages and some websites where the entire website actually is just a huge
flash application.

Note the term "flash application". "Flash" does not merely mean
"annoying media". As ridiculous as it sounds, Flash as been marketed as
an applications framework in some circles, and each website can be (and
often is) an entire application written in flash. So 10 tabs in a
browser can easily equate to 10 different applications of arbitrary
size/processing need/complexity written in stratopheric-level language.
The more vile web advertisement banners are mini-applications complete
with API imports and sub-processes running to track your viewing stats, etc.

All of this occurs within the plugin container, so that process will
look like a process hog at times. It is not being one on its own; its
all the child processes of it/running confined by it that are doing all
the spinning.

top/htop/ps/things-in-proc/whatever will show you all the processes,
this is true. But what it won't show you is a clear map of what process
is a child of what other process, and the current init system is not
capable of showing you grandfather+ or uncle/cousin relationships.

So, for example if:
1.  /bin/annoying spawns /bin/really-annoying which then spawns
/bin/ultra-annoying

2.  later /bin/irritant-police kills /bin/really-annoying

3.  The user cannot tell that /bin/ultra-annoying was originally linked
to /bin/annoying as a grandchild via an intermediate process, and there
is no way to tell if it has cousin or uncle processes which logically
belong to the same group.

This is one of the things that is being fixed (slowly and painfully) by
the implementation of systemd in Fedora which should wind up in the next
major version release from TUV. Maybe (if its ready).

So... its not as simple as just running top/htop or "ps -ae | grep"ping.

As far as undocumented things in Flash, there are lots. Its Adobe
software, after all.