After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 655190 - Sluggish performance interacting with calendar/tasks
Sluggish performance interacting with calendar/tasks
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Tasks
3.2.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-07-24 00:43 UTC by Thomas
Modified: 2013-09-13 01:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
eds patch (75.40 KB, patch)
2011-08-02 13:04 UTC, Milan Crha
committed Details | Review
evo patch (17.69 KB, patch)
2011-08-02 13:07 UTC, Milan Crha
committed Details | Review

Description Thomas 2011-07-24 00:43:27 UTC
Just created a new vm (vmware player 3.1.4) from ubuntu's daily build liveCD, that being a
11.10 oneiric. Updated all packages. evolution version is 3.1.3. Imported
all my calendars and tasks from an earlier evolution version.
Noticed that it takes noticeable delays interacting with the task list,
when switching between "Overdue Tasks", "completed tasks", "Tasks due the next 7 days" and "current tasks". Also, opening an individual task has a noticeable delay. Same in calendar when switching to an earlier month via arrow buttons or mouse wheel. I have a fairly fast machine (dual core intel processor).
Other applictions on the vm don't show such performance problems so far (Libre Office, firefox, gedit..)
I remember when I tested the first versions without bonobo (2.30, 2.32), there
was the same kind of slow interaction. 
How could I test this further?
Comment 1 André Klapper 2011-07-24 19:27:24 UTC
Latest Evolution version is 3.1.5... Maybe also ask on the evolution mailing list: http://mail.gnome.org/mailman/listinfo/evolution-list
Comment 2 Milan Crha 2011-08-01 14:08:17 UTC
Thanks for a bug report. This is mostly due to EClient changes I did, the calendar is doing many things synchronously, thus is not ready for an asynchronous design offered by EClient. Because EClient is fully asynchronous, it simulates synchronous calls by "invoke and wait for confirmation", which, when done really asynchronously, doesn't hurt that heavily.

I'm working on a "little" fix, as there seem to be an issue with properties, which calendar is asking repeatedly for, which makes it slow.
Comment 3 Milan Crha 2011-08-02 13:04:29 UTC
Created attachment 193056 [details] [review]
eds patch

for evolution-data-server;

Extends EClient API (both client and dbus APIs) to be able to notify about certain backend property change from a backend, and the EClient keeping cache of backend properties for quicker processing. This is done transparently. The backend base-struct doesn't notify about internal properties changes, that all is up to descendants. The e-client-utils from libedataserverui caches backend properties for later use.

The ECalClient provides new functions to generate instances for client or component asynchronously, except of timezone fetching, but that's not that big deal, as those were already cached once downloaded from the backend.
Comment 4 Milan Crha 2011-08-02 13:07:22 UTC
Created attachment 193057 [details] [review]
evo patch

for evolution;

Use new generate instances asynchronous functions where possible, and create new calendar views asynchronously as well. This makes a huge difference with UI response while changing view properties.
Comment 5 Milan Crha 2011-08-02 13:24:42 UTC
Created commit 549a80d in eds master (3.1.5+)
Created commit 5da21ce in evo master (3.1.5+)
Comment 6 Milan Crha 2011-08-02 14:33:11 UTC
And a little change in eds, which I added just before committing the above, and it makes freezing of evolution, thus I reverted it in:

Created commit 6a9e999 in eds master (3.1.5+)
Comment 7 Thomas 2011-08-04 13:24:39 UTC
(In reply to comment #4)
> Created an attachment (id=193057) [details] [review]
> evo patch
> 
> for evolution;
> 
> Use new generate instances asynchronous functions where possible, and create
> new calendar views asynchronously as well. This makes a huge difference with UI
> response while changing view properties.

That is much better now!! Just did a git pull and built it and interaction is
satisfactory. Tasks open a little slow, but still acceptable.
Comment 8 Milan Crha 2011-08-04 14:11:58 UTC
(In reply to comment #7)
> That is much better now!! Just did a git pull and built it and interaction is
> satisfactory. Tasks open a little slow, but still acceptable.

Does it block UI for you too (it should not) or just the time till events are shown takes longer, but you can interact with UI with no issue during that period?
Comment 9 Thomas 2011-08-04 14:56:36 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > That is much better now!! Just did a git pull and built it and interaction is
> > satisfactory. Tasks open a little slow, but still acceptable.
> 
> Does it block UI for you too (it should not) or just the time till events are
> shown takes longer, but you can interact with UI with no issue during that
> period?

Well, just a couple of hours ago, I had such a block when I could not switch
from Tasks to Calendar using the buttons, but I could not reproduce that so far.