Bug 869047

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.

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.

Created attachment 632165 [details]
log: gdb --batch --ex "t a a bt" -pid=4366

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.

I can see the same when opening gtk3-demo->Stock Item and Icon Browser, thus it's not about evolution, but about window complexity.

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.

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.

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.

Created attachment 633232 [details]
Sysprof output during starting and immediately cancelling new message.

I have now added the sysprof log.

It is unclear to me if window manager or display driver make a difference.

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.

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.

It appears to be better in 
evolution-3.7.1-1.fc19.x86_64
(still no speed king though, but probably comparable to fc17).

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
evolution-3.6.1-1.fc18.x86_64

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.

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

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