Bug 869047 - Opening New mail window (composer) in evolution causes gnome-shell and gtk3 using too much CPU (no animations involved)
Opening New mail window (composer) in evolution causes gnome-shell and gtk3 u...
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-22 17:14 EDT by Mark van Rossum
Modified: 2014-02-05 07:40 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-05 07:40:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
log: gdb --batch --ex "t a a bt" -pid=4366 (19.24 KB, application/octet-stream)
2012-10-23 11:29 EDT, Mark van Rossum
no flags Details
Sysprof output during starting and immediately cancelling new message. (1.07 MB, application/octet-stream)
2012-10-25 05:01 EDT, Mark van Rossum
no flags Details

  None (edit)
Description Mark van Rossum 2012-10-22 17:14:24 EDT
Description of problem:

I'm running evolution on a laptop with i5 cpu, 8Gb and ssd and
nothing much else is running.

Whenever I start composing a new message, cpu use shoots up to 100% for more than 5 seconds.
Cancelling the message takes about the same amount of cpu.

My evolution folder is largish (4k messages in Inbox), but this cpu use seems just a bit too much and it is noticeably annoying.
Furthermore, I don't think fc17 versions were so slow.

Version-Release number of selected component (if applicable):

Perhaps related to: 863164  ?
Comment 1 Milan Crha 2012-10-23 04:07:38 EDT
Thanks for a bug report. Could you get a backtrace of running evolution (with installed debuginfo packages for gtkhtml3, evolution-data-server and evolution) in the state of high CPU usage, which may give a clue what is causing the CPU usage, please? You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt
where PID is a process ID of running evolution (ps ax | grep evolution).

I'm aware of one issue in gtk3 with animations of spinner, which use to eat CPU significantly, just like you described. Whether this is the same issue as that yours I cannot tell yet.
Comment 2 Mark van Rossum 2012-10-23 11:28:27 EDT
I think it is not the spinner issue, as that is supposedly solved now,
nor does it seems graphics related.

Other observations: 
- It seems to get worse over time.
- Also switching between 'calendar' and 'mail' is sluggish.
Comment 3 Mark van Rossum 2012-10-23 11:29:31 EDT
Created attachment 632165 [details]
log: gdb --batch --ex "t a a bt" -pid=4366
Comment 4 Milan Crha 2012-10-24 15:36:35 EDT
Thanks for the update. The backtrace snap shows the process in initialization of a descendant of one gtk widget. I ran this in my virtual machine, together with sysprof running, and I tried to open and close a composer window multiple times, while the sysprof was catching what was going on. It showed me that evolution was far back in CPU usage, about 0.85%, while the top CPU usage was done by gnome-shell, about 42%, and the second was Xorg, which means, from my point of view, some drawing on the screen. The gtk_css_style_provider_lookup also eats about 1% of CPU, thus I believe this is about drawing in Fedora 18. I'm moving this to the gnome-shell, because it is the winner.
Comment 5 Milan Crha 2012-10-24 15:39:28 EDT
I can see the same when opening gtk3-demo->Stock Item and Icon Browser, thus it's not about evolution, but about window complexity.
Comment 6 Mark van Rossum 2012-10-24 15:58:09 EDT
On my machine, however, the gtk3-demo runs fine, not taking much CPU at all,
including 'spinner'.

I forgot to mention I'm running evolution under XFCE. 
I have yet to see if the bug persists when running gnome or KDE.
Comment 7 Mark van Rossum 2012-10-24 16:04:27 EDT
I also checked CPU use during creating a new email message
Evolution is taking 100%, the rest far less.

Thus we might be talking about separate problems here.
Comment 8 Milan Crha 2012-10-25 04:13:58 EDT
Mine machine is a virtual machine, thus it's using a software renderer, I suppose. Do you think it makes the difference? The 'top' command can show different values than 'sysprof', thus I suggested tot try sysprof to see what is eating the CPU on your machine.
Comment 9 Mark van Rossum 2012-10-25 05:01:04 EDT
Created attachment 633232 [details]
Sysprof output during starting and immediately cancelling new message.
Comment 10 Mark van Rossum 2012-10-25 05:04:28 EDT
I have now added the sysprof log.

It is unclear to me if window manager or display driver make a difference.
Comment 11 Milan Crha 2012-10-29 08:47:08 EDT
Thanks for the update. I see in the log that the most CPU users are [pool] (66.63%) and [evolution] (19.97%). The pool is mostly busy in handler_lookup and handlers_find. The same two functions are the most CPU usages in evolution itself too. Is your F18 installed as a real machine, or as a virtual machine, like mine? I'm wondering how much it makes a difference.
Comment 12 Mark van Rossum 2012-10-29 12:17:55 EDT
I can now confirm that this problem persists on another computer with 
a fresh evolution account.
Perhaps the problem is somewhat less severe on the second machine, but opening 5 compose windows (CTRL-N times 5), still takes many seconds.
It happens both under GNOME and under XFCE. I also found the handler_lookup taking most time.

Both cases are real machines with Intel graphics.
Comment 13 Mark van Rossum 2012-10-30 07:23:17 EDT
It appears to be better in 
(still no speed king though, but probably comparable to fc17).
Comment 14 Mark van Rossum 2012-11-06 17:30:16 EST
Switch to evolution-3.7.1-1.fc19.x86_64 did not help in the end.
It does get sluggish after a day or so.
Now back to
Comment 15 Fedora End Of Life 2013-12-21 04:10:21 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 16 Fedora End Of Life 2014-02-05 07:40:25 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.