Synaptic searches on UI thread

[Mike Benza]

Searches take a lot of processing power in synaptic. When you run a search, the search clearly runs on the UI thread, since the window becomes unresponsive and doesn't repaint itself. The search should be run on a separate thread to keep the UI responsive.

[Ameen Demidem (ameen.demidem)]

Can you please provide more details such as :
1- what was your search keyword
2- can you measure the time it took to give you an answer.
3- your HW configuration

I guess, if you are searching for something, you are supposed to wait for the search to finish. Except if it's really taking too much time and you want to cancel, maybe ? Can you be more clear about it ?

Cheers.

[Mike Benza (mikebenza)]

1. Any search keyword works. The lag is most noticeable when you have universe enabled since there are more packages to search. It is also most noticeable when you first use synaptic after you boot, since the information about the packages isn't cached in memory.
2. I don't have an accurate timer, but it's about 4-5 seconds. The time of the search isn't the issue, it's the fact that the search is done on the UI thread.
3. Core 2 Duo T7500 @ 2.2 GHz, 4GB Ram, 120GB disk

The issue is that any processor intensive task should not be run on the UI thread, since the UI thread should always be responsive. Canceling is an example of why you want a responsive UI thread.

[rgrig (radugrigore)]

With synaptic 0.62.7ubuntu6 (according to apt-cache policy synaptic, or 0.62.5 according to the About box :P) try searching for files. I mean, type "search for files". It is *very* slow. Takes about 10 seconds until becomes responsive again.

[rgrig (radugrigore)]

Here is a patch for
  https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu
On my computer, (quick) searching for "and" takes
 * about 25 seconds without the patch and
 * about 0.4 seconds with the patch.
That's about 60 times faster.

It seems the xapian API was misused. (Xapian docs say that get_mset() is faster if a low upper limit is provided, but they mean for *one* search.)

[Neil Perry (nperry)]

@rgrig I have attempted to use your patch with the latest synaptic from the lucid repo. However I am unable to patch as it is failing at line 47.

[rgrig (radugrigore)]

@Neil: As I clearly said, the patch is not for the Lucid branch.

The patch does two things,
a) fix use of xapian api, brings time from 25s to 0.6s
b) somewhat faster filtering of packages not in view, brings time from 0.6s to 0.4s
(all times on my computer, for the exmaple search i gave)

I discovered afterwards that (a) was also done in
  https://code.launchpad.net/~jibel/synaptic/jibel
(before I posted my patch, actually)

So you can try to merge that branch.

[Michael Vogt (mvo)]

The ~jibel branch is now merged, it does only do (a), for (b) there is still room for optimization in the code.

[Philip Muškovac (yofel)]

Addin patch so the reviewers team doesn't get auto subsribed again and patch-forwarded upstream as the patch known there.

[dino99 (9d9)]

That version is too old and no more maintained
This is not seen with the actual version.