update-manager cpu-bound for a long time opening

Bug #613743 reported by Daniel J Blueman
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
python-apt (Ubuntu)
New
Low
Julian Andres Klode
Declined for Maverick by Sebastien Bacher
update-manager (Ubuntu)
Fix Released
Low
Unassigned
Declined for Maverick by Sebastien Bacher

Bug Description

Binary package hint: python-apt

When opening update-manager on a linux system with poor X acceleration, eg with the Nouveau driver or the Radeon driver on newer hardware or power saving enabled, Xorg consumes 100% processor time, and update-manager can take (literally) 1-2 minutes to open.

Tags: patch
Revision history for this message
Daniel J Blueman (danielblueman) wrote :

I tracked this down to a very high frequency of GUI updates, when the 'Building data structures' progress bar is being updated.

With the attached patch, we still get many progress-bar updates and update-manager opens in now 5 seconds, rather than ~60s (or more with further power saving).

Changed in python-apt (Ubuntu):
status: New → Fix Committed
Revision history for this message
Julian Andres Klode (juliank) wrote :

Changing status to NEW again. We did not even take a look at it, and did not commit a fix in one of the repos. And the patch is not correct either, it should be done differently.

Changed in python-apt (Ubuntu):
assignee: nobody → Julian Andres Klode (juliank)
status: Fix Committed → New
Revision history for this message
Julian Andres Klode (juliank) wrote :

I have added update-manager to the affected packages, because I think that the bug should be fixed there, by adding a check that the progress is not updated more than about 25 times per second (or what ever else is useful).

I did not close the python-apt bug, as we might want to decrease the number of progress updates, and fix our GTK widgets as well.

Revision history for this message
Daniel J Blueman (danielblueman) wrote :

Oops - sorry for the marking with the wrong status.

With the recent update to libcairo for slow progress bar drawing, the number of progress bar updates is still needlessly high, making update-manager slow opening over a TCP socket, so this bug is still valid.

The patch changes a value (100) that was arbitrarily selected previously, so is not changing behaviour in any other way - other ways were evaluated, and this is the minimal change.

Revision history for this message
Julian Andres Klode (juliank) wrote :

Yes, but 2000 means 6% (currently it is 0.3%) which means that the progress bar will jump. The frontend should limit itself to an usable level of updates, that can not be the job of the code driving the progress. Just skip some updates in the frontend if the last update was less than n seconds ago (where 'n' defines how often you want to update)

Revision history for this message
Michal Matyska (michal-matyska) wrote :

Latest version of update-manager has been fixed:

update-manager (1:0.142.5) maverick; urgency=low

  * more python-apt 0.8 porting
  * less updates to the progressbar
  * DistUpgrade/DistUpgradeViewNonInteractive.py:
    - fix crash in non-interactive upgrader when a conffile prompt
      is detected

 -- Michael Vogt <email address hidden> Thu, 05 Aug 2010 22:49:07 +0200

Revision history for this message
Benjamin Drung (bdrung) wrote :

first patch was rejected, unsubscribing ubuntu-sponsors

Changed in update-manager (Ubuntu):
status: New → Fix Released
tags: added: patch
Changed in python-apt (Ubuntu):
importance: Undecided → Low
Changed in update-manager (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.