CPU usage increases dramatically (and visible stuttering) when running indicator-multiload

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

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.

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

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.

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.

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."

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).

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

Confirmed on Ubuntu 12.10 with Unity version 6.12.0.

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.

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.

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

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

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).

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

The indicator-multiload is heavy and the current Ubuntu implementation of the AppIndicator have a temporary questionable workaround that transform an all images from argb to rgba inside the compositor from gjs:

https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/005fe8b8280c2bdb65fa5927de2e2ed60def0480/appIndicator.js#L477-L490

But although the indicator-multiload is heavy, the video stutter should not happening just because of that. This is why i think there are also a shell problem behind that and this problem is really not new. Please see:

https://bugzilla.gnome.org/show_bug.cgi?id=687362

A lot of thing can block the compositor thread, but what is worse is that non one can know the next thing that will block it. Specially because it can come from a shell extension, as this is the case. So, I think that find a solution only to the case of the indicator-multiload, will not help in general to find a solution to the underlying problem.

One different way to reproduce the video stutter, can be create an extension that execute an spawn command line in a sync mode every 1 seconds (for example). Then if we open a video in firefox we can see the video stutter problem. In my opinion as same as the spawn_command_line_sync, the indicator-multiload is stopping the compositor thread and this is the real cause of the video stuttering. More over, any execution that delay the compositor thread tends to create the same effect. This can be, for example, the installation of a package that make a full apps menu update.

The indicator-multiload is complex, so it enough the delay that it will introduced in the compositor for the bad effect of stuttering to occur. Of course, executing spawn_command_line_sync in a gjs application, outside the compositor thread, does not generate the problem at all. Also as the indicator-multiload is not the only possible code that can delay the execution of the compositor thread, finding a solution with base on reducing the workload imposed by the indicator-multiload, is not really going to solve the general underlying problem.

I think move all GUI things of the shell (including extensions) outside the compositor thread, in a new process, should solved it, because that ensure that an arbitrary code of an extension can not block the compositor thread.

For what it worth that argbToRgba code (which I'd like to move to GdkPixbuf asap) isn't really used in indicator-multiload as it provides the actual icons to show, so the shell has "only" to paint them, and unfortunately this is something that looks somewhat slow.

The argbToRgba function is unfortunately a needed thing, but only for indicators providing pixmaps, that are in such format and we don't have access to other C code doing this better right now.

This is still an issue in a clean install, default config ubuntu 20.04 with all updates and indicator-multiload from the repo also in its absolute default config.

This makes it basically impossible to use multiload with 20.04 right now.

I'm on a dual screen with 4k and 2.7k (Surface pro 4) intel graphical chipset, i7 with 4 cores.

On a 20.04, using gnome-shell over Xorg, gnome-shell proc usage jumps from 0-3% to 40-60% usage when using indicator-multiload.

gnome-shell over Wayland will have same issue, with an added visible mouse stuttering problem.

interestingly, I've installed unity7 (with ubuntu-unity-desktop 0.2), and this doesn't occur on unity as dramatically: it goes from 2-4% without indicator-multiload to 6-8%. This makes it totally usable on unity.

indicator-multiload 0.4-0ubuntu5
gnome-shell 3.36.4-1ubuntu1~20.04.2
compiz-core 1:0.9.14.1+20.04.20200211-0ubuntu1

Confirming that this is an issue even with the Dell customized ubuntu 20.04 version for the Dell XPS 13 laptop.

I find about 30% cpu useage for gnome-shell when multiload-indicator is running.

I also find that high framerate, high res youtube videos stutter when multiload-indicator is running but they run much smoother when multiload-indicator is closed.

I am using an intel evo i7 processor and intel Xe graphics card.

I am still struggling to understand if there is an update to fix this.

I am typically using Gnome3 with ubuntu 20.04 (standard ubuntu).

Chris, please try to use the upstream version of this extension from https://github.com/ubuntu/gnome-shell-extension-appindicator/

It changes the way we handle indicator-multiload in a way that should improve performance.

This bug was fixed in the package gnome-shell-extension-appindicator - 53-1

---------------
gnome-shell-extension-appindicator (53-1) experimental; urgency=medium

  * New upstream release
  * appIndicator: Wait for style change if no stage is set
  * appIndicator: Reuse already imported namespaces
  * appIndicator Use Clutter to load RGBA Pixmap textures natively
  * appIndicator: Simplify loading of custom image files (LP: #784055, #1973358)
  * dbusMenu: Use more dbus async methods
  * interfaces-xml: Comment out the signal definitions (avoids gjs signals)
  * dbusMenu: Do not update menu items while the menu is closed
  * Util: Do not recreate the default theme each time
  * appIndicator: Only update icon size when it matters
  * appIndicator: Only perform updating actions if we're fully ready
  * appIndicator: Ensure St.Icon loading icon size matches theme and preferences
  * appIndicator: return the previous GIcon if something failed
  * appIndicator: Refactor named icons lookup and loading
  * appIndicator: Use correct update frequency on signals accumulator
  * appIndicator: Ensure that property emissions are queued together
  * dbusMenu: Use cancellable's to handle subsequent requests
  * dbusMenu: Populate menus in chunked idles
  * statusNotifierWatcher: Properly handle null services
  * dbusUtil: Filter introspectable bus by interfaces if provided
  * dbusUtils: Use more reasonable timeout for introspection
  * util: Use a recursive async generator to get introspection results
  * statusNotifierWatcher: Remove idle promise on bus seeking
  * debian/patches: Drop applied upstream

 -- Marco Trevisan (Treviño) <email address hidden> Mon, 13 Mar 2023 20:21:32 +0100

Do I need to checkout and compile from source or can I use the browser extension (i.e. gnome extension) to use the newer version?

If you're not using Ubuntu 23.04 then you can get the fixed version 53 of the extension from: https://extensions.gnome.org/extension/615/appindicator-support/

I was finally able to get the browser approach to work (advice: there is a little slider at the very top of the gnome-extensions-app GUI that you have to click to get the extensions to activate, or else you begin to lose your mind thinking that you have to install it manually from source because clicking on the slider next to Appindicator and KStatusNotifierItem wasn't doing anything when I clicked it).

I find that the CPU usage has improved. When I am running indicator-multiload in the top right corner (i.e. in the gnome status bar) I find that gnome-terminal takes up 7% of one of my cpu cores (and this drops to less than a percent when I turn off indicator-multiload). Earlier on 2022-03-01 I wrote that gnome-terminal was taking up 30% when I was running indicator-multiload (and of course it dropped to zero when I killed indicator-multiload)

So fixed version 53 is definitely an improvement (thanks!). I am not sure if the bug can be declared to be squashed but this is much better than it was.

Again I am using Ubuntu 20.04 which uses Gnome 3.36.8 by default.