|
Bugzilla – Full Text Bug Listing |
| Summary: | Package search slow | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Dirk Stoecker <opensuse> |
| Component: | YaST2 | Assignee: | 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
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. 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. 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. 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? 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. 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). *** This bug has been marked as a duplicate of bug 305571 *** |