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 678013 - the contacts search provider doesn't scale
the contacts search provider doesn't scale
Status: RESOLVED DUPLICATE of bug 677442
Product: gnome-shell
Classification: Core
Component: general
3.4.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-06-13 12:35 UTC by Ian Kumlien
Modified: 2012-06-13 12:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ian Kumlien 2012-06-13 12:35:29 UTC
libfolks extracts all users from evolution, in my case that is ~55498 users.

It's populated synchronously and it consumes ~2gb memory (res, not virt).

As far as i understand from reading some of the source, there is no way of turning this off - rendering gnome-shell basically useless.

(populating from *cached* data takes 2-3 minutes - nothing is responding. Searching this amount of data takes 1-2 minutes and again, the user can't do anything else than wait.)

I would like to be able to set and customize *all* search providers and do it easily (as in: user and/or system-global).
Comment 1 Ian Kumlien 2012-06-13 12:41:47 UTC
Considering the fact that libfolks notifies for each added/deleted contact, disabling the MAPI connector in evolution also led to a perceived-deadlock... =)
Comment 2 Florian Müllner 2012-06-13 12:51:40 UTC
The plan for now is to move contacts search into gnome-contacts, where it belongs.

There are some plans for making application search providers (read: all but application search) external and configurable, see https://live.gnome.org/GnomeShell/Design/Whiteboards/Search for the current status of the design.

*** This bug has been marked as a duplicate of bug 677442 ***
Comment 3 Ian Kumlien 2012-06-13 12:58:37 UTC
Ok, thanks, didn't find the first bug while searching.