compiz CPU usage increases dramatically when running indicator-multiload

Reported by Scott Moser on 2011-05-17
240
This bug affects 53 people
Affects Status Importance Assigned to Milestone
System Load Indicator
Low
Unassigned
The Ubuntu Power Consumption Project
Undecided
Unassigned
Unity
Low
Unassigned
libindicator
Low
Marco Trevisan (Treviño)
indicator-multiload (Ubuntu)
Low
Unassigned
libindicator (Ubuntu)
Undecided
Marco Trevisan (Treviño)
unity (Ubuntu)
Low
Unassigned

Bug Description

using 0.1-0~5~natty1 on mostly up to date natty system, when running the indicator-multiload with with just cpu monitor and the default update interval of 500 milliseconds, I see (via top) that compiz usage when generally idle goes from either 0 or 1% of CPU to 3 or 4% of CPU. Reducing the update interval does seem to have an affect.

I realize that
a.) top is not scientific
b.) there could be something I'm missing here
c.) saying "300%" (in the subject) is not scientific

Related branches

lp:~3v1n0/libindicator/reduce-image-serialization
Merged into lp:libindicator at revision 526
PS Jenkins bot: Approve (continuous-integration) on 2014-03-03
Lars Uebernickel: Approve on 2014-03-03
Michael Hofmann (mh21) wrote :

For comparison, on my system with metacity/gnome-panel, indicator-multiload+indicator-applet-complete need about 2% CPU at 100ms update interval.

summary: - compiz CPU usage increases ~300% when running indicator-multiload
+ compiz CPU usage increases to 4% when running indicator-multiload

Could you post some system specs for comparison (CPU, graphics card)?

But I fear that I can't do much here. Somebody needs to optimize the unity app-indicator code I think...

On Tue, 17 May 2011, Michael Hofmann wrote:

Thanks for responding very quickly.

> Could you post some system specs for comparison (CPU, graphics card)?

cpu is dual core. from /proc/cpuinfo:
 Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz

graphics card should be accelerated, and reasonably current, in a Lenovo
T400. From lshw:
 *-display:0
    description: VGA compatible controller
    product: Mobile 4 Series Chipset Integrated Graphics
Cer
    vendor: Intel Corporation
    physical id: 2
    bus info: pci@0000:00:02.0
    version: 07
    width: 64 bits
    clock: 33MHz
    capabilities: msi pm vga_controller bus_master cap_list rom
    configuration: driver=i915 latency=0
    resources: irq:46 memory:f4400000-f47fffff memory:d0000000-dfffffff ioport:1800(size=8)

>
> But I fear that I can't do much here. Somebody needs to optimize the
> unity app-indicator code I think...
..

I figure thats probably right.

> For comparison, on my system with metacity/gnome-panel, indicator-
> multiload+indicator-applet-complete need about 2% CPU at 100ms update
> interval.
>
> ** Summary changed:
> - compiz CPU usage increases ~300% when running indicator-multiload
> + compiz CPU usage increases to 4% when running indicator-multiload

I used the "300%" rather than "to 4%" as I think it contains more
information. "to 4%" doesn't mean anything as there is no baseline.

There is a dramatic increase in resources here, "to 4%" doesn't really
show that.

I know it sounds more dramatic :-).

But as 300% is relative to a variable baseline (which ideally would be 0), I consider 4% of a Core2 Duo to be more appropriate.

summary: - compiz CPU usage increases to 4% when running indicator-multiload
+ compiz CPU usage increases 0->4% when running indicator-multiload

I've added libindicator as an 'also affects'. if that is incorrect, please re-file appropriately.

Ted Gould (ted) wrote :

This isn't really what the indicator system was designed for, which is why the load is so high. It's encoding the images to go over DBus. There's not too much libindicator could do, I'd imagine there is more that could be done in unity-panel-service. Since it's outside the design, I'm marking it Wishlist.

affects: libindicator → unity
Changed in unity:
importance: Undecided → Wishlist
status: New → Triaged
Didier Roche (didrocks) on 2011-07-20
Changed in unity (Ubuntu):
status: New → Triaged
Michael Hofmann (mh21) wrote :

Is it really encoding the images over dbus? Watching a dbus-monitor, it looks like it is just sending the name (but this is with gnome-panel), so there is no real reason why 4% of 3GHz are needed for that.

Daniel van Vugt (vanvugt) wrote :

This sounds like essentially the same as bug 813409 but we won't be sure until (unless?) a fix is developed. In that bug I noted:

"Found the cause to be that my indicator-datetime is set to display seconds, not just hours and minutes. This seems to cause unity/compiz to send the SyncOne and SyncGeometries dbus messages to unity-panel-service every second. And profiling unity-panel-service with callgrind shows it is spending all it's time in g_variant_ fuctions, invoked by the dbus activity. So this needs to be optimized. It's quite wrong that something happening only once per second should use so much CPU."

Michael Hofmann (mh21) on 2011-09-13
Changed in indicator-multiload:
status: New → Confirmed
importance: Undecided → Wishlist
gcc (chris+ubuntu-qwirx) wrote :

This is higher than wishlist importance. This is a regression since the indicator applet used a reasonably low percentage of CPU on previous Ubuntus (e.g. Lucid and Maverick).

Changed in unity (Ubuntu):
importance: Undecided → Low
Changed in unity:
importance: Wishlist → Low
summary: - compiz CPU usage increases 0->4% when running indicator-multiload
+ compiz CPU usage increases dramatically when running indicator-multiload
Changed in indicator-multiload (Ubuntu):
status: New → Triaged
importance: Undecided → Low
PKink (pete-kinkead) wrote :

Same issue here.

CPU: model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

graphics:
          description: VGA compatible controller
          product: C61 [GeForce 6150SE nForce 430]
          vendor: NVIDIA Corporation

fwiw, date/time is not displaying seconds. Shutting off the CPU/network monitor indicator immediately ramped CPU load down to normal idle levels

papukaija (papukaija) on 2012-08-14
tags: added: battery-power-consumption
Robert Charlton (rectec) wrote :

Confirmed on Ubuntu 12.10 with Unity version 6.12.0.

Robert Charlton (rectec) wrote :

Also confirmed on a fresh install of Raring, if it hasn't been already. Fully updated as of writing. Seems to increase the CPU usage of unity-panel-service on Quantal, while it increases the CPU usage of compiz on Raring.

Michael Hofmann (mh21) on 2013-02-10
Changed in indicator-multiload:
importance: Wishlist → Low
Changed in indicator-multiload (Ubuntu):
status: Triaged → Confirmed
MC Return (mc-return) wrote :

The cause for this bug is actually bug #1182803:
A redraw of just one pixel in the Unity-panel will damage the whole screen instead of just damaging this pixel, so Compiz' CPU usage rises unnecessary, especially when indicator-multiload paints into the panel constantly. Once the Unity-damages-the-whole-screen-all-the-time problem is fixed this problem should be gone.

Bernie Innocenti (codewiz) wrote :

YES! Thanks for tracking this down, mc-return.

Changed in unity:
status: Triaged → Won't Fix
Changed in libindicator:
status: New → In Progress
importance: Undecided → Low
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libindicator - 12.10.2+14.04.20140304-0ubuntu1

---------------
libindicator (12.10.2+14.04.20140304-0ubuntu1) trusty; urgency=low

  [ Marco Trevisan (Treviño) ]
  * IndicatorImageHelper: always try to use a GIcon or the filename as
    source of the GdkImage We don't need to fallback to pure pixbuf,
    unless an indicator provided a custom icon that is not in the
    current theme path. This helps a lot in reducing the Unity7 workload
    as this decreases the cases where we need to encode the pixbuf
    contents, send them via dbus to unity, encode them back, reload to a
    new pixbuf... Also thanks to this, the library clients can load the
    actual icon, scaled at the value they want. (LP: #784055)
 -- Ubuntu daily release <email address hidden> Tue, 04 Mar 2014 10:58:35 +0000

Changed in libindicator (Ubuntu):
status: New → Fix Released
Changed in libindicator:
status: In Progress → Fix Committed
Changed in unity (Ubuntu):
status: Triaged → Invalid
Changed in libindicator (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)

Confirmed for 14.04 trusty. This bug is not fixed. (The comment “This bug was fixed in the package libindicator” is confusing.)

This is the maximum we can achieve inside unity, we already save a lot of CPU compared to the previous status.

The fact is that indicator-multiload swaps between two different icons, and due to that we also had to ignore the gtk icon caching (that would have brought even more performances).

Michael Hofmann (mh21) wrote :

Hi Marco,

would it help if the indicator would swap between icons that have a different name each time? Somebody would still need to make sure that the cache has an upper limit of cached icons...

Michael

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers