Bug 332059

Summary: Package search slow
Product: [openSUSE] openSUSE 10.3 Reporter: Dirk Stoecker <opensuse>
Component: YaST2Assignee: Stefan Hundhammer <shundhammer>
Status: RESOLVED DUPLICATE QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None    
Version: Final   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Dirk Stoecker 2007-10-09 06:28:01 UTC
In the software installation from Yast:

When I now use the search function a progress report pops up, which blocks the input. When I want to search something else, I either need to stop the search or wait until it finished. Previous SUSE version allowed to enter new search keywords during search or at least did not block the text field.

Solution: Either make the progress report non-blocking (and set focus to text field) or remove it and restore old behaviour.

This is especially disturbing, as the search is not cached and when I switch from another display (e.g. Installation status) to the search, it always restarts the obsolete search.
Comment 1 Stefan Hundhammer 2007-10-11 10:54:33 UTC
Of course that pop-up blocks its main window. It's a "busy pop-up". If you want to cancel the ongoing search, use its "Cancel" button.

If that was different in previous versions (which I find very hard to believe), that was a bug in those previous versions.
Comment 2 Dirk Stoecker 2007-10-11 11:12:59 UTC
Do you use your own tools? If not, try an openSUSE 10.2 yourself.

a) There is no pop-up at all in previous version, so it also can't block anything. I wrote that above.
b) It is possible to enter a new search when an old is still running (under 10.2). And not only a new search, but switch to other display modes, ...
c) It seems searching in 10.3 is about 3-4 times slower than 10.2 variant.

So 10.2 allowed to search in parallel, 10.3 blocks the whole application. This is a major regression.

And no, it was no bug in previous version, but the current one is a bug: Reduced flexibility.
Comment 3 Stefan Hundhammer 2007-10-11 11:31:20 UTC
What dialog are you talking about? I was referring to the detailed package selection. That's what the initial bug description appears to be about: "Package search" and "software installation".

This is the "Search" filter view in the detailed (Qt-based) package selection. This has ALWAYS had a pop-up. And it was always blocking.

So what dialog is this really about? Please attach a screen shot (of the main dialog, not the pop-up).

And YES, I USE MY OWN SOFTWARE. I don't need to be lectured about that.
Comment 4 Dirk Stoecker 2007-10-11 12:10:35 UTC
Sorry, but if you tell me I'm stupid you must accept the reply.

You're right, there is a delayed search dialog also in previous versions, which pops up after a little time (I needed to initiate a very deep search checking all fields to get it). Anyway in 10.2 I've never seen it, whereas in 10.3 it comes everytime.

So the bug is a bit different:
E.g. Searching "www" in Name/short description is finished immediately on 10.2, but takes about 5 seconds on 10.3 (nearly the same number and types of repositories).

Searching "lib" takes 130 seconds on 10.3, but is finished immediately on 10.2.

So the subject is indeed wrong, but the problem is there. But you can't blame me for wrong subject. I've never seen the dialog on 10.2 or older releases, so assuming it's a new one was not so wrong.

Maybe Qt changed a bit and now inserting new entries takes too much time?
Comment 5 Stefan Hundhammer 2007-10-11 12:28:49 UTC
The pop-up always is delayed for a short while because in some cases it will be done so quickly that it's not worth while opening a busy pop-up. This is to avoid flickering, and this is unchanged since SuSE 8.2.

The searching per se is slower now, that is true and a known issue. This is due to the fact that not all package meta data are now loaded upon startup any more. This has made startup faster, but of course when the data are needed they need to be loaded at least once. This is not a Qt issue. It's the way libzypp was optimized. But postponing that kind of thing doesn't mean that the CPU cycles involved with it never need to be invested, it only delays that.
Comment 6 Dirk Stoecker 2007-10-11 12:50:07 UTC
Then there is a big bug in here. When this is a loading issue, a second search for lib should be as fast as in 10.2. This is not the case. It always takes nearly the same time.

BTW: I don't see a speedup at startup (using about 5-6 buildservice repos and PackMan). A real speedup would be, if you could move the updating into background and give me immediate access to the package interface (with the problems in mind, which may arise in seldom cases, when my selections conflict with the inbetween done update).
Comment 7 Stefan Hundhammer 2007-10-11 13:18:48 UTC

*** This bug has been marked as a duplicate of bug 305571 ***