! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfce-battery-plugin: high cpu and mem usage


Description Alexey Privalov 2007-02-26 08:31:10 CET
Hi all,

I have quite strange and high (high for such application) cpu usage:
88288 lucky   1  97    0 47540K 11460K select   4:32  3.42% xfce4-battery-plugi
27290 lucky   1  96    0 27364K 19420K select   2:30  0.05% sim
15187 lucky   4  20    0 12368K  8536K kserel  19:36  0.00% xmms
78261 lucky   1  96    0 12404K  7804K select   1:11  0.00% xfce4-wavelan-plugi
18050 lucky   1  96    0 51504K 16328K select   0:35  0.00% xfce4-panel

sim and xmms both are using much less cpu than battery-plugin! is it ok? )

also is it normal that plugin use so much memory? 

I have a Compaq Evo n610c laptop.

> uname -a
FreeBSD ontario 6.2-STABLE FreeBSD 6.2-STABLE #12: Fri Feb 23 18:35:47 NOVT 2007     root@ontario:/usr/src/sys/i386/compile/ontario  i386

> dmesg
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-STABLE #12: Fri Feb 23 18:35:47 NOVT 2007
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1196.12-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Stepping = 7
real memory  = 536674304 (511 MB)
avail memory = 519979008 (495 MB)
kbd1 at kbdmux0
ACPI: overriding DSDT/SSDT with custom table
    ACPI-0377: *** Info: Table [DSDT] replaced by host OS

there are following changes was made in ACPI table: added two buttons (power and sleep), LID Switch fixed.

> pkg_info | grep xfce4-bat
xfce4-battery-plugin-0.5.0_1 Battery monitor panel plugin for XFce4

under Xfce 4 Desktop Environment version 4.4.0 (Xfce 4.4)
Comment 1 Alexey Privalov 2007-02-26 11:04:53 CET
*** Bug 2949 has been marked as a duplicate of this bug. ***
Comment 2 Alexey Privalov 2007-02-26 11:05:27 CET
*** Bug 2950 has been marked as a duplicate of this bug. ***
Comment 3 Harald Servat 2007-03-01 10:37:30 CET

  I've the same "problem" (FBSD 6.2, IBM T42p). Maybe the updating frequency is too high?

Comment 4 Alexey Privalov 2007-03-01 10:48:48 CET
I've thought the same... but it doesn't seem to be the truth...
I've recompiled the source with other values for updating frequency... a result was the same for me..
Comment 5 Álvaro Lopes 2007-03-01 22:44:18 CET
Does the memory consumption seem to grow over time, or it starts like that?
Comment 6 Alexey Privalov 2007-03-02 03:51:14 CET
just starts like that
Comment 7 Scott H 2007-05-05 16:02:07 CEST
I'm seeing the same problem.. the cpu usage is the more worrisome issue to me. Top is showing between 3 and 8% of cpu usage by xfce4-battery-plugin on a p3 1.2ghz machine.

If it's not polling too frequently, perhaps it's something on the gtk+ side? Although I don't even have a visible label now, just the bar, so I can't imagine why that would cause it.
Comment 8 Harrisony 2007-05-12 02:44:37 CEST
Confirmed on Linux (Ubuntu)
Although cant change OS field to All 
Comment 9 Alexey Privalov 2007-05-22 05:12:52 CEST
made some improvment and fixes there. so, now it takes less the 1% of CPU:

 1116 lucky         1  97    0 34276K 20108K select   0:07  0.29% xfce4-battery-plugi

what was fixed and added:
   - improve and optimize logic and calculations during polling
   - remove unneeded callings to graphics each time
   - fixed FreeBSD APM code
   - status more sensitive now.. based on APM_BATT_STATE and ACPI_BATT_STATE (except that this works under *BSD only...)
   - text size of lables is calculated automaticly now

tested under fBSD only...
Comment 10 Alexey Privalov 2007-05-22 05:13:46 CEST
Created attachment 1151 
patch 2007_05_22
Comment 11 Alexey Privalov 2007-05-29 02:44:49 CEST
fixed by patch
Comment 12 Nick Schermer editbugs 2007-06-08 08:09:45 CEST
A bug with patches that is resolved, without /me looking at it.
Comment 13 Scott H 2007-08-13 03:04:04 CEST
Any chance of this patch getting committed?
Comment 14 Nick Schermer editbugs 2007-08-13 18:20:37 CEST
I will apply them, test and release next week.
Comment 15 Nick Schermer editbugs 2007-08-17 18:55:24 CEST
Ok I'm sorry to say this Alexey, but the patch is a mess. It might or might not solve the problem, but it's completely unreadable and I'm not going to apply a patch which I'm not 100% sure that it works on all the Unixes the plugin supports.
Comment 16 Alexey Privalov 2007-09-02 05:59:45 CEST
hi there,

Oh man, don't say sorry to me.. it's ok.. just want to say some things.

first of all, I've said already that it's tested under fBSD only.. even not `tested' but `written under/for' it... cauze have only this OS.

yeah, the patch quite large and may seems to be a mess or whatever else... I perfectly understand that reading not your own code is most complicated thing...
but, you know, things doesn't depend on our opinions of it.. it just is... 

everything what I know are:
1. 'battery' plugin has a very unoptimised code
2. my patch makes some optimisation under my system... it's just one of much ways in this area of course
3. it works for me (see earlier posts with numeric results)

don't have enough time to fix it for all systems.
just want to share it with the community. and it's your decision to accept it or to decline..
Comment 17 Yves-Alexis Perez editbugs 2007-10-31 20:52:38 CET
The patch is indeed a terrible mess, it's unreadable. The original code isn't that clear either, and it seems there's a lot of g_timeout_add() calls, I don't know if some of them don't overlap.

Alexey, woult it be possible to clean the patch and split it into multiple simple and independant parts?


Yves-Alexis Perez
Comment 18 Yves-Alexis Perez editbugs 2007-11-05 12:07:31 CET
It seems that the high cpu usage may be due to the gtk progress bar.
If you comment out gtk_progress_bar_set_fraction() in battery.c, it drops down and the plugin isn't constantly polling.

Having progress bar to show constant informations may not be a really good idea, finally. I don't know what will be the correct solution:
- disabling progress bars as a configuration option
- remove completely progress bar and find another way to display information
- ...

Regards, and thanks for your work,

Yves-Alexis Perez
Comment 19 Sasha Medvedev 2017-03-30 23:21:49 CEST
It seems that the update logic doesn't work as expected. I noticed that when the battery is full the percent value jumps randomly between 99 and 100 percent. This is probably due to my buggy battery controller, but anyway it says that battery status update happen every 1-2 sec for some reason.  Changing ALL timeouts in g_timeout_add calls to 30 seconds fixes the CPU issue for me.
Comment 20 Git Bot editbugs 2020-05-22 23:07:40 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/panel-plugins/xfce4-battery-plugin/-/issues/1.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #2948

Reported by:
Alexey Privalov
Reported on: 2007-02-26
Last modified on: 2020-05-22
Duplicates (2):


Xfce-Goodies Maintainers
CC List:
4 users


0.5.1 or older


patch 2007_05_22 (42.88 KB, patch)
2007-05-22 05:13 CEST , Alexey Privalov
no flags

Additional information