Gradual degradation in desktop performance.

Bug #888039 reported by jhfhlkjlj
334
This bug affects 95 people
Affects Status Importance Assigned to Milestone
Unity
Fix Released
Critical
Jason Smith
unity (Ubuntu)
Fix Released
Critical
Ron Karoles
Oneiric
Won't Fix
High
Daniel van Vugt

Bug Description

SRU test case:

1. start Ubuntu and use it for a few hours
2. After the constant usage of a few hours there general performance degrade noted
3. now install NUX from oneiric-proposed
4. The situation is much imporved

=====Original Report====
edit - This bug has been scoped down to a particular std:vector<int> growing out of control inside of nux. Any report about degrading performance not related to this should be filed as new bugs. :) Thanks guys.

Over the span of 1-3 days I see my desktop consistently become more sluggish. The functions most affected are window movement, file icon movement, and sometimes window resizing. Other animations (such as minimizing fades, switching desktops, expo mode) are not affected when this degradation occurs. They remain smooth; however, I have let the problem go on as long as to find out that eventually all desktop animations/effects will degrade, it just takes a lot lot longer. I find that my actual 3D gaming goes unaffected (though I have no data to back that up, perhaps it does).

I have recorded the output of 'ps auxw' and have slowly watched the VSZ and RSS memory columns creep upwards. A fresh compiz session will see 675164 and 169860, respectively. After a day or two it will result in as high as 878552 and 255664. I have attached a log output from an hourly cron job (though I had suspended for a few days because of travel).

After the degradation has occurred compiz will consistently use higher CPU. Dragging a terminal window while watching top: before: ~10%, after: ~30 percent.

This has been an issue since 11.04 for me on both my Intel i915 and Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX, both having the same issue). However, the nvidia machine is where it really hurts, _always_ happening within a day or two, while the i915 machine is pretty reliable overall with certain instances of degradation (used to be affected just as badly in 11.04).

I will attach two videos demonstrating behavior before and after.
---
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CheckboxSubmission: 33c9cec13de798ee31ce4ea2f2cbd4df
CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
CompizPlugins: [core,detection,composite,opengl,decor,regex,winrules,compiztoolbox,animation,grid,vpswitch,snap,place,gnomecompat,resize,move,mousepoll,imgpng,workarounds,session,expo,wall,fade,scale,unityshell]
DistroCodename: oneiric
DistroRelease: Ubuntu 11.10
DistroVariant: ubuntu
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
NonfreeKernelModules: nvidia
Package: compiz 1:0.9.6+bzr20110929-0ubuntu5vv1
PackageArchitecture: all
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Tags: oneiric running-unity oneiric running-unity ubuntu
Uname: Linux 3.0.0-12-generic x86_64
UnreportableReason: This is not a genuine Ubuntu package
UpgradeStatus: Upgraded to oneiric on 2011-10-13 (26 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Related branches

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :
tags: added: apport-collected oneiric running-unity ubuntu
description: updated
Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : Dependencies.txt

apport information

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : GconfCompiz.txt

apport information

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : ProcEnviron.txt

apport information

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :
Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I will swap out this video for another one as this isn't great quality nor demonstrates the entire impact of the bug, only showing the window dragging. I'm on a fresh session right now, however, so I need to wait a day... :)

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Some things I have tried that have made no difference:

I have installed Daniel van Vugt's PPA and tried his compiz build.
I have reset all Compiz settings to factory.
I have disabled the 'Bailer' plugin
I have disabled Auto refresh rate detection and put mine in manually.
I have disabled dynamictwinview from my xorg.conf.
I have enabled "Force sync between X and GLX" in CCSM's 'workarounds' plugin
I have enabled "Force Full Screen Redraws" in CCSM's 'workarounds' plugin.

description: updated
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz (Ubuntu):
status: New → Confirmed
Revision history for this message
Rocko (rockorequin) wrote :

I see this bug on both an intel system and an nvidia system as well. The benchmark that shows the degradation is glxspheres, available in the virtualgl package (which is installable via apt-get if you do sudo apt-add-repository ppa:mj-casalogic/ironhide). glxspheres drops from around 60 fps to as low as 25 fps when the degradation is apparent.

I notice the opposite in RAM usage, however - compiz typically is using less RAM when I see the degradation. And it often comes on quite quickly. It might be related to having a few windows open (I typically run Netbeans, VirtualBox, Firefox, Thunderbird) or it might be related to using a lot of RAM. Sometimes the degradation persists across multiple reboots (and for multiple users), but when this happens there is never any degradation using metacity or mutter.

I've documented a lot of what I've tried at bug #861061 and how the problem sometimes randomly resolves itself.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Very odd that it resolves itself for you. It gets consistently worse and worse for me.

Revision history for this message
Rocko (rockorequin) wrote :

When I say it resolves itself, it never does so spontaneously. It sometimes resolves after a complete PC reboot, and once or twice when I tried unity --reset and unity crashed spectacularly.

Also if I disable the unity plugin, it resolves itself immediately, so like Daniel suspects in bug #861061 it may well be that unity is at fault rather than compiz.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

can the unity plugin be disabled without a restart to compiz itself? If so, then I will make sure to try that out when it flares up again.

Revision history for this message
Rocko (rockorequin) wrote :

I'm pretty sure you can just disable it by unticking it in ccsm, but I'm not sure if that unloads it immediately. I was 'lucky' enough to have unity completely crash on me a few times without crashing compiz, and on at least one occasion it disabled itself completely from ccsm so logging in gave me just a desktop with the gnome-terminal that I always run (for emergencies like that if nothing else).

Revision history for this message
Rocko (rockorequin) wrote :

OK, I just experienced the slowdown and tried the following:

1. Test glxspheres: ~30-40 fps

2. Open ccsm and disable the unity plugin. I think that restarts compiz but it restarts without unity (all the other windows are still there).

3. Test glxspheres: ~60 fps

4. From ccsm, re-enable the unity plugin. Again, compiz seems to restart and this time unity is back.

5. Test glxspheres: ~30-40 fps.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

There is a chance the degradation in some cases is caused by the composite rendering timer drifting out of sync with your monitor. And it does, I know that for certain. When this happens, tearing becomes more visible and the frame rate can go down to half of what it should be.

*If* that is the issue for you then this fix is likely to solve it:
https://code.launchpad.net/~vanvugt/compiz-core/fix-880707/+merge/81737

The fix will be available for testing in a PPA after it's been approved by more reviewers... It will be worth trying at least.

Revision history for this message
Rocko (rockorequin) wrote :

Thanks for the update. I'm more than happy to try it, anything to improve the unity experience! Right now glxspheres is running at 33 fps, whereas an hour ago it could manage 56fps - and I haven't done anything in the meantime other than eat dinner! Let me know when the PPA is available.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

isn't the glxspheres problem covered by bug 861061? It seems like we're starting to have separate issues, Rocko.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

How embarrassing. I forgot to remove the audio from my "after" video.

I've updated it.... Can't make another one yet as it's not bad enough to warrant a video at the moment.

Revision history for this message
Rocko (rockorequin) wrote :

I do see the same issue as you when performance drops - windows move 'jerkily', by not moving with the mouse and then suddenly jumping a large number of pixels all at once. The worst I have seen it get is that the mouse will move and the window not at all until a second after the mouse stops moving.

I use glxspheres because it provides numbers to describe the drop in performance. Typically glxspheres has much lower fps at the same time as the desktop becomes sluggish so I assume they are related.

I originally opened bug #861061 when the drop in performance had apparently become permanent, ie persisting across reboots. At some point it automagically resolved itself but has returned a number of times since. I suspect they may be the same bug but Daniel says is experiencing a permanent drop in performance and wants to use 861061 to track this permanent drop in performance.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I don't know if this is helpful but if I move windows around in expo mode it's very butter smooth again.

description: updated
Revision history for this message
Lorenzo Villani (lvillani) wrote :

I confirm that I can see this bug also when using Catalyst (fglrx) drivers (both the version available in Oneiric and later versions avaiable from AMD's website).

In my case the issue is exacerbated by the number of active X clients. Closing some windows slightly improves the situation. However, I noticed this behavior in addition to performance degradation over time.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

People using Catalyst fglrx drivers should make sure they have the fix for bug 763005 installed first. Because bug 763005 is more severe and will prevent you from being able to tell which bugs if any still remain.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Testing a new NVIDIA card with the NVIDIA driver 280, I think I can reproduce this bug now. It starts off smooth but if I drag windows around for a little while, it becomes jerky. The jerkiness often doesn't go away, but sometimes does if I leave everything idle for a while. Even with the workaround for bug 763005 applied the jerkiness stays.

Now for the good news:
This bug appears to be fixed when I install my compiz fix for bug 880707. Awesome :)

The bad news:
The fix for bug 880707 is undergoing a minor redesign by the compiz team so I can't make it public until that's done.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

In the previous comment, "bug 763005" should read "bug 92599".

Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → In Progress
Changed in compiz (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
status: Confirmed → In Progress
Revision history for this message
peter huwe (pjhuwe) wrote :

I've been struggling with what seems to be the same bug.

Summary: When I log in, compiz and all my programs run ridiculously fast. Over the course of the next 30 hours (give or take), it gradually become sluggish and jerky. If I log out and log back in again, then it goes back to being fast.

Details: It's a nice, new, sexy computer. i7-2600K Sandy Bridges processors, 16GB RAM, SSD, GeForce GTX 570, current NVIDIA driver, dual screens with twinview, running Ubuntu 11.10 with Unity.

When I log in, everything runs really, really fast with beautiful graphics. Gradually, things slow down (after maybe 6 hours). Programs which rely on OpenGL and normally use ~15%CPU will start using 100%CPU. Temp never exceeds 52 degrees F though, and RAM usage is low. Video memory usage stays low. No swap usage at all. My window switching becomes very choppy. To fix everything, all I have to do is log out and log back in. But 7 or 8 hours later, the same issues pop up. Reverting to Natty doesn't help at all.

I first noticed this problem while using the graphics intensive program, VMD. But the problem is definitely not limited to that program. I even experience choppy window switching when I have no programs open. I've tried a billion things, but nothing has remedied the problem yet.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Hmm, perhaps the problem I reproduced was not this bug. Everyone else seems to say it takes hours or days. But I was able to get some degradation using the nvidia-driver in under a minute (!). When the proposed fix is available for testing we will of course know for certain if it's a different issue.

Revision history for this message
Florin Coras (fcoras) wrote :

Well, at least we're two. I can reproduce this bug on my laptop with an Nvidia NVS 140M shortly after a restart. For me, the sluggishness/jerkiness never goes away. This might have to do with my card being a bit outdated.

Same holds for bugs 861061 and 880707. So, I'm really looking forward to a compiz (and unity) fix Christmas present.

Daniel, thanks for writing and pushing for the fix!

Revision history for this message
Matt Pharoah (mpharoah) wrote :

I also am getting this bug after "minutes".

The thing is, it's not actually time. Here is the behaviour I am getting:

When attempting to move a window (ANY window, not just one with transparency) in GNOME Classic using Compiz, the very first time you click the window and drag it around it works fine. After that, any other time you click the window and drag it around, it won't update its position AT ALL unless you keep your cursor in the same position for about 1/4 of a second, at which point it will update.

I tried toggling the lazy option in Compiz's move plugin, but it had no effect.

Then I tried the half-fix posted here by Daniel, and it worked perfectly (though obviously repainting the entire screen on an update is not desirable!) I'm back to using Compiz again. I'll probably just make a shell script wrapper for my games that temporarily switches to Metacity until the program terminates.

Revision history for this message
Achim (ach1m) wrote :

Exüberance, I think you have this bug → https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/874514

Revision history for this message
Matt Pharoah (mpharoah) wrote :

Perhaps I do, because this fix suddenly stopped working and I have no idea why.

Revision history for this message
Rocko (rockorequin) wrote :

@Exüberance: the redirect option might help for windowed games. You have to install compiz-plugins-extra and then you have 'Extra WM Actions', which allows you to assign a key combination to toggle redirect for a particular window. It works even when compiz is struggling to move windows around.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Game performance under Unity is probably better covered in bug 861061.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Experimental fixes for this and related performance bugs are now available
for testing in ppa:vanvugt/compiz and ppa:vanvugt/unity. For the best
results I recommend trying both together. But testing them individually is
useful too.

IMPORTANT NOTES:

  * The fixes in ppa:vanvugt/compiz REQUIRE that "Sync To VBlank" is ENABLED
    in CompizConfig Settings Manager (OpenGL section).
    This is the default setting when Ubuntu 11.10 is installed.

  * When using ppa:vanvugt/compiz you should DISABLE the workaround
    "Force full screen redraws (buffer swap) on repaint" in
    CompizConfig Settings Manager (Workarounds section).
    This is the default setting when Ubuntu 11.10 is installed.

  * I don't claim to have fixed all tearing. I only claim that the amount of
    tearing in oneiric with the fix is no longer worse than in natty.

  * nouveau: If you are using the "nouveau" driver for NVIDIA chips you will
    need to enable sync-to-vblank support in the driver options because
    nouveau has it disabled by default. You can do this by editing
    /etc/X11/xorg.conf and adding:
       Section "Device"
           Identifier "My Graphics"
           Option "GLXVBlank" "on"
       EndSection
    Then log out and in again for it to take effect.

  * fglrx (Catalyst): The fglrx driver also disables sync-to-vBlank support
    by default. To fix this:
      1. Open Catalyst Control Center.
      2. Go to 3D > More Settings.
      3. Set "Wait for vertical refresh" to
         "On, unless application specifies".

  * Please don't try using the Benchmark plugin in compiz-plugins-extra
    because it is broken and misleading (bug 898548).

Please leave feedback in the relevant bug reports.

- Daniel

---

ppa:vanvugt/compiz | https://launchpad.net/~vanvugt/+archive/compiz
compiz (1:0.9.6+bzr20110929-0ubuntu6vv2) oneiric

  * Added proposed fix for inaccurate frame timing causing tearing and
    stuttering.
    (LP: #880707) (LP: #888039) (LP: #92599) (LP: #798868) (LP: #876575)

ppa:vanvugt/unity | https://launchpad.net/~vanvugt/+archive/unity
unity (4.24.0-0ubuntu2b1vv4) oneiric; urgency=low

  * Fix major performance regressions due to unnecessary UnityFBO binding
    (LP: #861061) (LP: #880707)
    UnityFBO was being bound even when not required. This caused major lag in
    glPaintOutput, which slowed down all rendering. This was seen in reduced
    framerates in apps (LP: #861061) and significantly worse screen tearing
    with Unity 4.x compared to 3.x (LP: #880707).

Revision history for this message
Rocko (rockorequin) wrote :

With unity+compiz from the PPA on sandy bridge graphics, I have so far encountered one instance of degradation (but it's nowhere near as bad as before).

The degradation is that I see some tearing when moving a window around (which no longer happens immediately after login) and occasionally the window 'freezes' for a second before jumping over to where the mouse now is.

glxspheres is doing something similar: it reported 59, 59, 42, 59, 59, 42, 59, 59, 42,... ie every few seconds it was stuttering and losing framerate, then recovering.

A minute later I still see the tearing but glxspheres seems to have totally recovered. The 'freeze' when moving a window around is also much improved.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think the "freeze" issue is probably more accurately described by a different bug. I've seen several people make reference to such long pauses in other bugs but don't know if anyone has given it a unique bug ID yet.

Revision history for this message
Rocko (rockorequin) wrote :

OK, perhaps it is another bug. Anyway, after a suspend/resume I'm now seeing the 'jumpy' or 'jerky' animation when moving windows just like before, including where the window stops moving completely (freezes) until you stop moving the mouse, even if it's 10 seconds later. To get the window moving animation to work, you have to move the mouse really slowly. glxspheres is still at 59fps, though.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Please log a bug for the "freeze" problem if you can't find an existing one. And subscribe me too.

I think we have to be careful to treat it as a different issue to stuttering, which so far I have classified as 20-30 FPS. If you're waiting a couple of seconds (i.e. 0-1 FPS) then the root cause of that problem is going to be something different.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Come to think of it, a frame rate of 0-2 FPS might be fixed by this:
https://code.launchpad.net/~vanvugt/compiz-core/fix-priority/+merge/81952

But I'm not game to add it to the PPA unless I can reproduce the bug. And with my current code I can't reproduce or test the bug the fix was designed to address :P

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I take that back. I've queued up the timer priority fix in my PPA since it's already been accepted for upstream compiz. Could take hours to be built and published though...

compiz (1:0.9.6+bzr20110929-0ubuntu6vv4) oneiric; urgency=low

  * Fix timer scheduling priority. It was set too high, which starved compiz'
    own event loop of X and GLX events. This caused all sorts of tearing,
    stuttering and hang-related bugs.

 -- Daniel van Vugt <email address hidden> Mon, 05 Dec 2011 15:34:10 +0800

compiz (1:0.9.6+bzr20110929-0ubuntu6vv3) oneiric; urgency=low

  * Improved the frame timing fix (previous commit) to also avoid excessive
    lag when doing fullscreen repaints. This means you can once again use the
    compiz workaround "Force full screen redraws (buffer swap) on repaint" if
    you want.

 -- Daniel van Vugt <email address hidden> Mon, 05 Dec 2011 14:41:03 +0800

Revision history for this message
peter huwe (pjhuwe) wrote :

Daniel, you are a wizard. It's been two days since I installed your PPA, and I haven't had any degradation problems since. Fingers crossed that I didn't just jinx it. Thanks for all your work!

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I've been using it and I still get the degradation. However, I had forgotten to disable "Force full screen redraws (buffer swap) on repaint".

Sadly, I'm going to have to leave my desktop until next Monday so I won't be able to test the really hurt machine for a bit :(. I hope that unchecking that option will fix it!

Revision history for this message
peter huwe (pjhuwe) wrote :

Never mind. I jinxed it. Still getting performance degradation. Sad day.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

If Chauncellor confirms the bug is still present with my PPA then I will unassign myself from it, because that means this is not the bug I thought it was.

Although, reviewing the bug description I am a little suspicious of unity-window-decorator and how it might interact with the compiz process (decorator plugin). When the degradation happens next, please open a terminal and run:

nohup unity-window-decorator --replace &

Does that restore performance?

Revision history for this message
Florin Coras (fcoras) wrote :

Hi Daniel,

As previously mentioned, despite using your ppa, I'm also getting the performance degradation. Unfortunately, the command you just posted does not restore the performance either. However, if I am to compare performance after degradation sets in, I think (no measurements though) that the interface is a bit more snappier after installing your fixes.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Understood. It is just correct practice to get feedback from the person who created the bug. That's because very often the people subscribing to a bug logged by someone else actually have a different issue, and it takes a long time to realize.

I'm not saying that's definitely the case here. But correct practice is to get final confirmation from the bug reporter.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

My intel laptop hasn't really gotten much better. It's not the really badly affected one (it was the nvidia desktop), but it's not up to the performance of Mutter.

As Florin stated, it has been snappier (though animations have an odd tendency to be slow-motion as the system load is higher).

I'm sorry that I can't report on my desktop for a while :/.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

No problem. We can wait.

The "slow-motion" animations will be directly related to the timing fixes I did in compiz. That should have been fixed in ppa:vanvugt/compiz version "vv3" and later.

Although one of the (good) side-effects of fixing the timing and general graphics smoothness is that everything might look a little slower. Because you're seeing more unique frames per second than you would without the PPA. That doesn't mean it's actually slower. Is it??

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

It definitely is slower :).

The more my CPU is used the slower it gets. If I'm running rather intense processes then the animations will slooooooowly (but accurately!) perform. So it is nice and smooth, just slower as the computer becomes more active.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

1. Are you still using ""Force full screen redraws (buffer swap) on repaint" ?

2. Do the animations become fast (during intense processes) if you have Sync To Vblank disabled?

Revision history for this message
Joar Jegleim (joar-jegleim) wrote :

I'm having the exact symptoms as described initially in this bug.
I've seen the same problem both with nouveau as well as with nvidia proprietary 280.13 in Oneric, note that I haven't been seriously testing that bit, I've just been switching between the two for the last 2-3 months as a result of problems described in this bug.
I've got Nvidia GT9800 .
I'm giving Daniel van Vugt's patches a go, just installed
compiz=1:0.9.6+bzr20110929-0ubuntu6vv5
compiz-core=1:0.9.6+bzr20110929-0ubuntu6vv5
compiz-gnome=1:0.9.6+bzr20110929-0ubuntu6vv5
compiz-plugins-default=1:0.9.6+bzr20110929-0ubuntu6vv5
compiz-plugins-main-default=1:0.9.6-0ubuntu4vv1
libdecoration0=1:0.9.6+bzr20110929-0ubuntu6vv5
unity=4.24.0-0ubuntu2b1vv4
unity-common=4.24.0-0ubuntu2b1vv4

I'll have to wait for at least 4-5 days until I can confirm if these packages resolved or improved these problems.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I'm not using "Force Full screen redraws on repaint", and I disabled "Sync to Vblank" and, for good measure, pulled a 'compiz --replace'

I started up minecraft and switched desktops. Nice and slow. But less smooth ;).

Would you care for a video or are the descriptions enough? Also, should this be in another bug since this isn't really an official release of compiz?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

No need for another bug, because the code you're using isn't released yet. I am still working on improving it even today. And comments like yours are important feedback that I'm considering...

P.S. Maybe a good workaround is to enable "Force full screen redraws (buffer swap) on repaint" while disabling "Sync To VBlank". That *should* revert to old-style timing while also eliminating tearing.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

All -

The issue with moving windows not being redrawn is probably best covered by bug 773861. Please subscribe to that one if it affects you.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Okay, my laptop is hit with it. Aside from the super-slow motion, dragging windows has hit that threshold of painful choppy movement. compiz --replace fixed it right up.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I'm now convinced this bug is not related to the fixes I have in progress. Sorry I can't help any more right now. It does look like degradation caused by a resource bloat or a leak...

Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → nobody
status: In Progress → Confirmed
Changed in compiz (Ubuntu):
assignee: Daniel van Vugt (vanvugt) → nobody
status: In Progress → Confirmed
Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

That's too bad. I'll keep your ppa active on my machines and report to see if any changes ever occur. Does smspillaz have a stable PPA with tweaks like yours that I should also check out?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

No smspillaz does not appear to have any PPAs except an empty one. I'm not aware of smspillaz having many performance bugs assigned to him, but this one looks like it might be related: bug 882826

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It looks like the high-variability in timing (AKA slow animations) might be fixed by the timer scheduling fix of bug 897045. I'll put that fix in ppa:vanvugt/compiz soon...

Revision history for this message
Matt Pharoah (mpharoah) wrote :

Well I got my window moving bugs (it was a mouse polling issue) and screen tearing issues all figured out, but it turns out that I actually DO have this bug after all- it just wasn't the cause of my other issues.

After leaving my laptop on overnight will downloading a torrent, I noticed that moving windows around was kind of jerky, only update at maybe 2 frames per second. Actual update within windows themselves was perfectly fine, but moving the windows around was no longer smooth.

Restarting compiz (compiz --replace) brought the speed back up to normal, so I can confirm this performance decrease on my computer.

Revision history for this message
Matt Pharoah (mpharoah) wrote :

Of course, restarting compiz produces bug 903512 which is even worse.

By the way, is there any way to edit comments on Launchpad? I often get an idea or think of something to add after writing a comment, but have to double-post since I can't find any edit button.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

mr-exuberant, if when moving windows you only see updates ~2 frames per second then please subscribe to bug 773861 which I believe covers that issue.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I now think this bug is a duplicate of bug 770160... ?

Revision history for this message
Matt Pharoah (mpharoah) wrote :

I don't think my problem is bug 773861 since the decrease in updates of window movement decays over time, and is perfectly fast for the first few hours of use. I've subscribed to bug 770160 though.

Revision history for this message
Rocko (rockorequin) wrote :

Although peter huwe said in comment #25 that he sees degradation when swap is not in use, I suspect that the degradation tends to happen on my system when swap starts being used, almost as if compiz/unity is having its data swapped out to disk which then slows it down. Typically on my system some process will use a ton of memory (firefox, Netbeans) that causes the system to hit swap, and afterwards the windows stagger around when I move them instead of moving smoothly.

It *is* a different issue from the slowdown I used to see in glxspheres, because I've seen glxspheres perform normally when the windows are staggering around.

One nice observation I have is that the versions of unity/compiz from Daniel's PPA seem to recover by themselves from the degradation a while after I close down the offending process using lots of memory (although not immediately), which is far better than before.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sounds like a problem with I/O, which I noticed a long time ago in 11.04. Unity and/or compiz seems to be severely affected by a busy disk. I agree it makes no sense -- why should the GUI be affected by disk activity at all... ? The bug description only mentions an increase of 200MB. While that's large, it shouldn't cause a huge change in the amount of swapping, unless caused by other processes.

I think I saw someone had logged a bug for this elsewhere. Don't know the ID.

Chauncellor, can you confirm your problem is linked to the amount of disk/swap activity? If not then it should be discussed in a different bug.

Revision history for this message
Rocko (rockorequin) wrote :

It's not just caused by high I/O, though. I have the staggering windows problem at the moment after a suspend/resume cycle and atop -d shows /dev/sda at only 1%-2% activity.

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Most definitely not involved with I/O. I am very much thinking that any I/O issues are related to the CFQ scheduler as its sluggishness is well-known and documented in bug 381300. While it's marked as fix released a plethora of individuals have claimed that the issue persists. If they are certain that it's I/O related I feel that that's a different bug because this isn't intermittent, it gradually (and pretty predictably) "happens".

Also, I have 8 gigs of RAM. I never bog the system down enough for the system to justify swap usage (and I'm a blenderhead).

Revision history for this message
Matt Pharoah (mpharoah) wrote :

I don't think this is linked to swap activity. I'll have to let my computer stay on overnight to make sure, but I've never seen my computer use more than half my ram (and I only have 4GB), let alone start using swap space.

The only time I've even seen swap space used is that a couple kilobytes stay in swap after resuming from suspend for some reason.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

OK then. If there is an issue related to swapping, please discuss it elsewhere.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The issue with ppa:vanvugt/compiz causing animations to play in "slow-motion" should now be fixed if you update to ppa:vanvugt/compiz version 1:0.9.6+bzr20110929-0ubuntu6vv8.

Revision history for this message
Joar Jegleim (joar-jegleim) wrote :

I see regression with the latest vv10 update . I was running vv8 before xmas, had a week holiday and when I came back (my computer was on for the whole time) my computer was still responsive and I noticed no lag. After I upgraded to vv10 monday 2. january (I missed vv9 'cause I was away) I've noticed some lag / jerkiness when switching virtual desktops . I've been away since tuesday 3. , came back friday 6. and the lag / jerkiness is even worse. I also see in top that compiz uses ~50% cpu while switching virtual desktops. compiz uses RES 325MB and VIRT 968MB but I don't have any numbers on what it initially was ... I'm not a 100% sure where to report this, I'm following this bug as well as 773861 and 764330 . But I comment here since to me it still look like the initial report in this bug "[...]Over the span of 1-3 days I see my desktop consistently become more sluggish.[...]" .
NOTE: the lag I've got now is noticeable, but it's nothing compared to what it was like before I started testing out vanvaugts patch'es. The lag now is more like estethical, a littlebit annoying but not much more
UPDATE: jan. 9., today the lag is as bad as it was back when I started following these bugs, and before I started testing vanvaugt's ppa. As of now compiz uses 85%cpu and RES 377m and VIRT 1040m ...

Revision history for this message
Joar Jegleim (joar-jegleim) wrote :

I found compiz, compiz-core, compiz-gnome, compiz-plugins-default and libdecoration0 version vv8 in my apt cache, I'll downgrade and see how that'll work out.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Joar, it does sound like this is your bug. In that case, you are likely to confuse the situation by downgrading.

Please try sticking with vv10 and just rebooting first. If rebooting solves the problem then you do have this bug. Changing your package versions will confuse the situation and make it unclear whether the logout/reboot or downgrade solved the problem.

Revision history for this message
Joar Jegleim (joar-jegleim) wrote :

Daniel: I may have been unclear, I've always reboot'ed after each upgrade from your ppa. F.example when I came back from xmas and upgraded from vv8 -> vv10 I tok a reboot, and I did the same now after downgrading (I rebooted) .
A reboot always help, and as described initially in this bug report I see gradual degradation over time (days) .
My computer was running on vv8 over xmas (more than a week) and I saw no degradation, but vv10 gave me degradation for each day in the span 2nd jan. -> 9th jan.

I was thinking more in the lines of downgrading to vv8 now and see if degradation occurs when I'm using the computer (mabye it didn't occur over xmas because the computer was idle) .

Revision history for this message
Joar Jegleim (joar-jegleim) wrote :

UPDATE: I see degradation with vv8 as well. Difference between now and the xmas holiday is that my computer hasn't been in idle.
So I'll upgrade to vv10 again and see how things go .
I'll try and register some more data running vv10 this time (memory usage and so on) and see how things go.
Btw.: I haven't enabled the "Force full screen redraws (buffer swap) on repaint" , I'll do that now .
And should I set sync to vblank in nvidia-settings (?)

Revision history for this message
Michael Knap (michael-knap) wrote :

I just wanted to chime in here. I've been searching for this bug on Launchpad for some time ! There are so many compiz / unity bugs, there seems to be a lot of noise on each bug report with intersecting symptoms. This makes it so hard to really identify and isolate a particular bug ! Anyway, I wanted to provide my own data about this bug.

I want to stress that my experience seems to be like that of Chauncellor and Peter Huwe above.

To recap:
With a fresh boot and login, there is a nice snappy desktop with compiz effects; at this time, one wouldn't think there is anything wrong. After time however, the desktop becomes sluggish.

I investigated with top. I consistently saw compiz cpu usage climb; it is important to note that memory usage does not seem to climb, just CPU usage ! So I ran

top -b | grep compiz >> outfile

I let this run for 24-36 hours on one machine with Oneiric, and on another machine with Natty. Both machines are up to date for their respective distros, and both machines are using nvidia cards and the nvidia provided driver. Finally both machines are running TwinView.

I parsed the data in outfile and made these plot with matlab. I am working on some more tests and documentation for each machine, but the nature of this bug takes time.

Revision history for this message
Michael Knap (michael-knap) wrote :

I was trying to add two sets of data to my last post. Here is the other one. Please note the titles in the plots.

What I would like to learn to do if a developer could point me in that direction is attach to the compiz process, and actually try to see what is process in compiz is eating the CPU. I cat attach with gdb, but I want to output the currently running function. My thinking is that after some time, one is more likely to be caught inside the process which is eating the CPU. With enough data points, we should statistically be able to track down which process (or maybe several processes) is unstable.

Speculating here... could this be a loop that slowly increases with time ? This linear degradation is a nasty bug !

By the way, two questions with launchpad:
1. How can I attach multiple files to a comment ?
2. Can I edit the description of an attachment on a previous comment ?

Revision history for this message
Michael Knap (michael-knap) wrote :

I should add that if I shutdown my Natty box, reboot into the Oneiric partition, then I get the same previous results: a linearly increasing CPU usage with compiz. So, it is not machine-dependent.

Finally, on an Oneiric install with the same nvidia hardware, but not running TwinView, I have not seen this degradation. I am working on further documenting that test at the moment. Maybe its there, but has a smaller slope ?

Revision history for this message
Bernie Innocenti (codewiz) wrote :

> I just wanted to chime in here. I've been searching for this bug on Launchpad for some time !
> There are so many compiz / unity bugs, there seems to be a lot of noise on each bug report
> with intersecting symptoms. This makes it so hard to really identify and isolate a particular
> bug !

Indeed. Regrettably, few Canonical engineers seem to be stepping in to analyze these bugs. Does anyone know who are the in-house maintainers of Compiz and why they don't appear to be paying much attention to the bug tracker?

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

There's a lot of work being done here, and there are a few canonical engineers that are working day in and day out on Compiz. Don't take the work they do lightly; Compiz was an unmaintainable mess when it was inherited; They're trying to sort it out.

Regardless, this bug report should not be commented upon unless any pertinant information is to be had.

Revision history for this message
Michael Knap (michael-knap) wrote : Re: [Bug 888039] Re: Gradual degradation in desktop performance.
Download full text (3.7 KiB)

Chauncellor, are you running Twinview by any chance ?

Michael Knap

http://michaelknap.net
Instructor and Researcher
Mathematics and Controls Engineering
Center of Excellence in Information Systems
Tennessee State University

On Fri, Jan 27, 2012 at 10:12 PM, Chauncellor <email address hidden> wrote:
> There's a lot of work being done here, and there are a few canonical
> engineers that are working day in and day out on Compiz. Don't take the
> work they do lightly; Compiz was an unmaintainable mess when it was
> inherited; They're trying to sort it out.
>
> Regardless, this bug report should not be commented upon unless any
> pertinant information is to be had.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  after: ~30 percent.
>
>  This has been an issue since 11.04 for me on both my Intel i915 and
>  Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX,
>  both having the same issue). However, the nvidia machine is where it
>  really hurts, _always_ happening within a day or two, while the i915
>  machine is pretty reliable overall with certain instances of
>  degradation (used to be affected just as badly in 11.04).
>
>  I will attach two videos demonstrating behavior before and after.
>  ---
>  ApportVersion: 1.23-0ubuntu4
>  Architecture: amd64
>  CheckboxSubmission: 33c9cec13de798ee31ce4ea2f2cbd4df
>  CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
>  CompizPlugins: [core,detection,composite,opengl,decor,regex,winrules,compiztoolbox,animation,grid,vpswitch,snap,place,gnomecompat,resize,move,mousepoll,imgpng,workarounds,session,expo,wall,fade,scale,unityshell]
>  DistroCodename: oneiric
>  DistroRelease: Ubuntu 11.10
>  DistroVariant: ubuntu
>  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
>  NonfreeKernelModules: nvidia
>  ...

Read more...

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

No.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Michael, to find the cause of high CPU usage you need a profiler, not a debugger.

Most profilers need special code compiled in to your application, but Valgrind has a plugin Callgrind that works with any existing binary (as do all valgrind plugins):
    http://valgrind.org/docs/manual/cl-manual.html

Callgrind will give you nice sorted lists of the functions using the highest CPU. It is not for beginners though. Maybe later I will write a HOWTO on profiling compiz with callgrind so more people can give it a go and provide some nice rich data on compiz performance.

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (4.1 KiB)

Thank you Daniel,

I am installing valgrind now. I have used a profiler for another
language. I 'll see what I can learn with google and man. On the
other hand, if I am attached to the running compiz with gdb, is there
a way to state the currently running function ? I would still like to
test my idea if only for curiosity. Suppose every 30 seconds I have
gdb output the active function. I am curious if as compiz eats more
CPU, the output function will be more likely to be the function that
is the cause.

On Sat, Jan 28, 2012 at 3:01 AM, Daniel van Vugt <email address hidden> wrote:
> Michael, to find the cause of high CPU usage you need a profiler, not a
> debugger.
>
> Most profilers need special code compiled in to your application, but Valgrind has a plugin Callgrind that works with any existing binary (as do all valgrind plugins):
>    http://valgrind.org/docs/manual/cl-manual.html
>
> Callgrind will give you nice sorted lists of the functions using the
> highest CPU. It is not for beginners though. Maybe later I will write a
> HOWTO on profiling compiz with callgrind so more people can give it a go
> and provide some nice rich data on compiz performance.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  after: ~30 percent.
>
>  This has been an issue since 11.04 for me on both my Intel i915 and
>  Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX,
>  both having the same issue). However, the nvidia machine is where it
>  really hurts, _always_ happening within a day or two, while the i915
>  machine is pretty reliable overall with certain instances of
>  degradation (used to be affected just as badly in 11.04).
>
>  I will attach two videos demonstrating behavior before and after.
>  ---
>  ApportVersion: 1.23-0ubuntu4
>  Architecture: amd64
>  CheckboxSubmission: 33...

Read more...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Michael, I thought about it and using a debugger may be appropriate. Because callgrind (and valgrind in general) will slow down compiz/unity to an almost unusable speed. You won't want to run it that way for long enough to even reproduce the gradual degradation. Also, the "gradual degradation" will be drowned out by the constantly poor performance of running under valgrind/callgrind anyway.

Using gdb you can use the "bt" or "where" commands to show the full call stack, which is useful. HOWEVER there is a lot to get right before the data is useful...

1. You need to choose the correct thread in the compiz process, or else you're looking at a useless stack. Probably thread 1, or whichever thread has "main ()" at the bottom.

2. You need to collect the full call stack (all functions) to be useful, not just one function.

3. You need many samples. A process using 20% CPU will only show you the offending call stack 1 in 5 attempts, on average. The rest of the time it will be idle and show you nothing useful. So you need many many samples.

It seems like a lot of effort to use gdb. In a previous life I used to ask my users to use "pstack" (on Solaris) which is a simple command that did all the debugger steps you need in a single command. If you can find a "pstack" alternative for Linux and run it many times then that would be easiest, fastest, and least invasive to your system.

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (4.7 KiB)

Thank you again, Daniel. I will see what I can do to gather some
data. I have already checked on pstack. Ubuntu packages a version but
only for i386; alas, I am running x86_64. I may be able to setup a
machine at work as a testbed, though.

On Sat, Jan 28, 2012 at 11:51 PM, Daniel van Vugt <email address hidden> wrote:
> Michael, I thought about it and using a debugger may be appropriate.
> Because callgrind (and valgrind in general) will slow down compiz/unity
> to an almost unusable speed. You won't want to run it that way for long
> enough to even reproduce the gradual degradation. Also, the "gradual
> degradation" will be drowned out by the constantly poor performance of
> running under valgrind/callgrind anyway.
>
> Using gdb you can use the "bt" or "where" commands to show the full call
> stack, which is useful. HOWEVER there is a lot to get right before the
> data is useful...
>
> 1. You need to choose the correct thread in the compiz process, or else
> you're looking at a useless stack. Probably thread 1, or whichever
> thread has "main ()" at the bottom.
>
> 2. You need to collect the full call stack (all functions) to be useful,
> not just one function.
>
> 3. You need many samples. A process using 20% CPU will only show you the
> offending call stack 1 in 5 attempts, on average. The rest of the time
> it will be idle and show you nothing useful. So you need many many
> samples.
>
> It seems like a lot of effort to use gdb. In a previous life I used to
> ask my users to use "pstack" (on Solaris) which is a simple command that
> did all the debugger steps you need in a single command. If you can find
> a "pstack" alternative for Linux and run it many times then that would
> be easiest, fastest, and least invasive to your system.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  afte...

Read more...

Revision history for this message
Ben Gamari (bgamari) wrote :

Daniel, this seems like exactly the task for a statistical profiler such as perf (https://perf.wiki.kernel.org/).

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (4.9 KiB)

I have installed perf, and am gathering some data. I am afraid my data
may be slightly skewed, though, as I am seeing nvidia stuff topping
the list of performance hogs. But, I thought that someone above had
commented that they see the same bug even without nvidia hardware. I
have a couple of machines I can test with, but they all have nvidia
cards.

Currently, on the machine from which I am reporting, compiz has
climbed to about 8% CPU usage. I ran perf record -p {compiz PID} for
only a few seconds.

I then ran perf report to get the following output.

# Events: 2K cycles
#
# Overhead Command Shared Object
# ........ ....... ...............................
....................................................................................................................................
#
    23.72% compiz libnvidia-glcore.so.280.13 [.] 0x1213c01
    15.94% compiz libnux-graphics-1.0.so.0.1600.0 [.]
__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > > std::__find<__gnu_cxx::__normal_iterator<int*,
std::
     9.67% compiz [kernel.kallsyms] [k] 0xffffffff81031dba
     4.64% compiz libc-2.13.so [.] __cfree
     3.84% compiz libc-2.13.so [.] _int_malloc
     3.74% compiz libc-2.13.so [.] __GI___libc_malloc
     1.91% compiz libGL.so.280.13 [.] 0x71d95
     1.71% compiz libc-2.13.so [.] _int_free
     1.29% compiz libcomposite.so [.]
CompositeWindow::damaged()

Of course, there is more output. I can attach it if anyone would like
to see it. I will use perf some more as compiz CPU escalates.

On Sun, Jan 29, 2012 at 9:45 AM, Ben Gamari <email address hidden> wrote:
> Daniel, this seems like exactly the task for a statistical profiler such
> as perf (https://perf.wiki.kernel.org/).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  Aft...

Read more...

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (6.9 KiB)

Here is some more data. Before I left work on Friday, I rebooted my
work machine and left it running. Since the reboot, it is now up to
32% CPU usage. This was a clean reboot. I didn't start any other
running process other than ubuntu's default desktop.

I ran perf top -p {compiz PID} :

   PerfTop: 311 irqs/sec kernel: 1.6% exact: 0.0% [1000Hz
cycles], (target_pid: 1898)
-----------------------------------------------------------------------------------------------------------------------------------------------------

             samples pcnt function
                                               DSO
             _______ _____
__________________________________________________________________________________________
_______________________________

             4302.00 96.7% __gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > > std::__find<__
libnux-graphics-1.0.so.0.1600.0
               24.00 0.5% __libc_malloc
                                               libc-2.13.so
               20.00 0.4% cfree
                                               libc-2.13.so
               16.00 0.4% nux::Layout::DoneRedraw()

/usr/lib/libnux-1.0.so.0.1600.0
                9.00 0.2% PrivateGLScreen::paintOutputRegion(GLMatrix
const&, CompRegion const&, CompOutput*, unsign
/usr/lib/compiz/libopengl.so
                8.00 0.2% PluginClassHandler<GLWindow, CompWindow,
3>::get(CompWindow*)
/usr/lib/compiz/libopengl.so
                8.00 0.2% nux::WindowCompositor::RenderTopViews(bool,
std::list<nux::ObjectWeakPtr<nux::BaseWindow>,
/usr/lib/libnux-1.0.so.0.1600.0
                5.00 0.1% CompWindow::id()
                                               /usr/bin/compiz
                5.00 0.1% CompositeWindow::damaged()

/usr/lib/compiz/libcomposite.so
                5.00 0.1% _nv012250rm
                                               [nvidia]

On Sun, Jan 29, 2012 at 10:25 AM, Michael Knap <email address hidden> wrote:
> I have installed perf, and am gathering some data. I am afraid my data
> may be slightly skewed, though, as I am seeing nvidia stuff topping
> the list of performance hogs. But, I thought that someone above had
> commented that they see the same bug even without nvidia hardware. I
> have a couple of machines I can test with, but they all have nvidia
> cards.
>
> Currently, on the machine from which I am reporting, compiz has
> climbed to about 8% CPU usage. I ran perf record -p {compiz PID} for
> only a few seconds.
>
> I then ran perf report to get the following output.
>
> # Events: 2K cycles
> #
> # Overhead  Command                    Shared Object
> # ........  .......  ...............................
> ....................................................................................................................................
> #
>    23.72%   compiz  libnvidia-glcore.so.280.13       [.] 0x1213c01
>    15.94%   compiz  libnux-graphics-1.0.so.0.1600.0  [.]
> __gnu_cxx::__normal_iterator<int*, std::vector<int,
> std::allocator<int> > > std::__find<__gnu_cxx::__normal_iterator<int*,
> std::
>     9.67%   compiz  [kernel.kallsyms]                [k] 0xffffffff81031dba
>     4.64%...

Read more...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thanks. Nux is the graphics library that Unity is built on. And that std::vector<int>::find at the top looks suspicious. Most certainly any code trying to do such a linear search into a vector will degrade over time if the size of the vector continues to grow.

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

As an aside, I also saw this a awhile ago, and grepped through the sources to find vectors of ints, but didn't find any in nux, unity or compiz. Perhaps there's a typedef.

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (3.6 KiB)

Yeah... I feel like this is a start. I was hoping to stir the waters a
little bit here.
Eagerly awaiting a fix.

Shouldn't this bug at least be triaged soon ! This is a good lead with
data. I will do what I can to provide more data if someone just tells
me what they need .

On Sun, Jan 29, 2012 at 8:16 PM, Daniel van Vugt <email address hidden> wrote:
> Thanks. Nux is the graphics library that Unity is built on. And that
> std::vector<int>::find at the top looks suspicious. Most certainly any
> code trying to do such a linear search into a vector will degrade over
> time if the size of the vector continues to grow.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  after: ~30 percent.
>
>  This has been an issue since 11.04 for me on both my Intel i915 and
>  Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX,
>  both having the same issue). However, the nvidia machine is where it
>  really hurts, _always_ happening within a day or two, while the i915
>  machine is pretty reliable overall with certain instances of
>  degradation (used to be affected just as badly in 11.04).
>
>  I will attach two videos demonstrating behavior before and after.
>  ---
>  ApportVersion: 1.23-0ubuntu4
>  Architecture: amd64
>  CheckboxSubmission: 33c9cec13de798ee31ce4ea2f2cbd4df
>  CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
>  CompizPlugins: [core,detection,composite,opengl,decor,regex,winrules,compiztoolbox,animation,grid,vpswitch,snap,place,gnomecompat,resize,move,mousepoll,imgpng,workarounds,session,expo,wall,fade,scale,unityshell]
>  DistroCodename: oneiric
>  DistroRelease: Ubuntu 11.10
>  DistroVariant: ubuntu
>  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
>  NonfreeKernelModules: nvidia
>  Package: compiz 1:0.9.6+bzr20110929-0ubuntu5vv1
>  PackageA...

Read more...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

More likely std::vector<Foo> where typedef int Foo.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I see 21 different results for vector<int> in the nux source. Plus there will be more from typedefs.

It's a start, but we need more specific information like a call stack before this bug can be marked as Triaged.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Subscribing Jay, in case he can shed some light on the issue;

4302.00 96.7% __gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > > std::__find<__
libnux-graphics-1.0.so.0.1600.0

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

More careful searching of the affected library, and "vector" near "find" yields something worth investigating:

RunTimeStats.cpp: std::vector<int>::iterator it;
RunTimeStats.cpp: it = std::find (_texture_2d_array.begin(), _texture_2d_array.end(), NUX_STATIC_CAST (IOpenGLBaseTexture *, GraphicsObject)->GetOpenGLID() );
RunTimeStats.cpp: std::vector<int>::iterator it;
RunTimeStats.cpp: it = std::find (_texture_rect_array.begin(), _texture_rect_array.end(), NUX_STATIC_CAST (IOpenGLBaseTexture *, GraphicsObject)->GetOpenGLID() );
RunTimeStats.h: std::vector<int> _texture_2d_array;
RunTimeStats.h: std::vector<int> _texture_rect_array;

Maybe those vectors are leaking... ?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Admittedly it should probably be using std::set (find = O(lgN)) instead of std::vector (find = O(N)). But we might be looking at the wrong code completely...

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (5.1 KiB)

I just wanted to say that there is seems to be no evidence of memory
usage growing. I am not sure how a vector could be growing without
memory growing.I guess it could be growing in a pre-allocated space,
though. But another update... the work pc shows compiz now at 47%
since Fri afternoon. I ran another perf top -p compizPID on it. I
think my previous output was truncated, so here is another output with
more info in the line. I guess this is some kind of a trace. Maybe it
will help. Finally, I will have to restart compiz on my work pc
tomorrow. Is there any more info anyone would like to gather while we
have an opportunity to get to this bug ?

   PerfTop: 372 irqs/sec kernel: 1.9% exact: 0.0% [1000Hz
cycles], (target_pid: 1898)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

             samples pcnt function

                                         DSO
             _______ _____
__________________________________________________________________________________________________________________________________________

                 _______________________________

             5419.00 97.0% __gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >
std::__find<__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > >, int>(__gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >,
__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > >, int const&, std::random_access_iterator_tag)
libnux-graphics-1.0.so.0.1600.0

Thank you for all input and work !

Michael Knap

http://michaelknap.net
Instructor and Researcher
Mathematics and Controls Engineering
Center of Excellence in Information Systems
Tennessee State University

On Sun, Jan 29, 2012 at 9:34 PM, Daniel van Vugt <email address hidden> wrote:
> Admittedly it should probably be using std::set (find = O(lgN)) instead
> of std::vector (find = O(N)). But we might be looking at the wrong code
> completely...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  se...

Read more...

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (5.7 KiB)

Sorry about the text in the post. I wanted to give you guys something
better, so I ran perf record for a a few seconds. I then perf report
>> perf_report.

The report is attached. It might be easier to read.

Michael Knap

http://michaelknap.net
Instructor and Researcher
Mathematics and Controls Engineering
Center of Excellence in Information Systems
Tennessee State University

On Sun, Jan 29, 2012 at 10:10 PM, Michael Knap <email address hidden> wrote:
> I just wanted to say that there is seems to be no evidence of memory
> usage growing. I am not sure how a vector could be growing without
> memory growing.I guess it could be growing in a pre-allocated space,
> though. But another update... the work pc shows compiz now at 47%
> since Fri afternoon. I ran another perf top -p compizPID on it. I
> think my previous output was truncated, so here is another output with
> more info in the line. I guess this is some kind of a trace. Maybe it
> will help. Finally, I will have to restart compiz on my work pc
> tomorrow. Is there any more info anyone would like to gather while we
> have an opportunity to get to this bug ?
>
>   PerfTop:     372 irqs/sec  kernel: 1.9%  exact:  0.0% [1000Hz
> cycles],  (target_pid: 1898)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>             samples  pcnt function
>
>
>
>
>                                         DSO
>             _______ _____
> __________________________________________________________________________________________________________________________________________
>
>
>
>                 _______________________________
>
>             5419.00 97.0% __gnu_cxx::__normal_iterator<int*,
> std::vector<int, std::allocator<int> > >
> std::__find<__gnu_cxx::__normal_iterator<int*, std::vector<int,
> std::allocator<int> > >, int>(__gnu_cxx::__normal_iterator<int*,
> std::vector<int, std::allocator<int> > >,
> __gnu_cxx::__normal_iterator<int*, std::vector<int,
> std::allocator<int> > >, int const&, std::random_access_iterator_tag)
> libnux-graphics-1.0.so.0.1600.0
>
>
> Thank you for all input and work !
>
>
> Michael Knap
>
> http://michaelknap.net
> Instructor and Researcher
> Mathematics and Controls Engineering
> Center of Excellence in Information Systems
> Tennessee State University
>
>
>
> On Sun, Jan 29, 2012 at 9:34 PM, Daniel van Vugt <email address hidden> wrote:
>> Admittedly it should probably be using std::set (find = O(lgN)) instead
>> of std::vector (find = O(N)). But we might be looking at the wrong code
>> completely...
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/888039
>>
>> Title:
>>  Gradual degradation in desktop performance.
>>
>> Status in Compiz:
>>  Confirmed
>> Status in “compiz” package in Ubuntu:
>>  Confirmed
>>
>> Bug description:
>>  Over the span of 1-3 days I see my desktop consistently become more
>>  sluggish. The functions most affected are window movement, file icon
>>  movement, and sometimes window resizing. Other ...

Read more...

Revision history for this message
Jason Smith (jassmith) wrote :

Im looking into it and have found the primary cause of the problem. There is a combination of a misbehaving indicator and a GUID loss issue going on here. I will try to have this resolved today.

affects: compiz (Ubuntu) → unity (Ubuntu)
affects: compiz → unity
Revision history for this message
Jason Smith (jassmith) wrote :

The linked branch should resolve the issue. Simply put there were a LOT of 0's in that list. The tracker should have been ignoring GUID 0 (its not valid and represents a client side texture) but was not accurately doing this.

Changed in unity:
status: Confirmed → Fix Committed
importance: Undecided → Critical
assignee: nobody → Jason Smith (jassmith)
milestone: none → 5.2.0
Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (3.4 KiB)

Great ! Thank you Jason, Daniel, Ben, devs, and others for the work on
this thread this weekend. I hope I have been more helpful then
troublesome. Looking forward to testing a patch soon !

On Sun, Jan 29, 2012 at 10:50 PM, Jason Smith <email address hidden> wrote:
> Im looking into it and have found the primary cause of the problem.
> There is a combination of a misbehaving indicator and a GUID loss issue
> going on here. I will try to have this resolved today.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Compiz:
>  Confirmed
> Status in “compiz” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  after: ~30 percent.
>
>  This has been an issue since 11.04 for me on both my Intel i915 and
>  Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX,
>  both having the same issue). However, the nvidia machine is where it
>  really hurts, _always_ happening within a day or two, while the i915
>  machine is pretty reliable overall with certain instances of
>  degradation (used to be affected just as badly in 11.04).
>
>  I will attach two videos demonstrating behavior before and after.
>  ---
>  ApportVersion: 1.23-0ubuntu4
>  Architecture: amd64
>  CheckboxSubmission: 33c9cec13de798ee31ce4ea2f2cbd4df
>  CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
>  CompizPlugins: [core,detection,composite,opengl,decor,regex,winrules,compiztoolbox,animation,grid,vpswitch,snap,place,gnomecompat,resize,move,mousepoll,imgpng,workarounds,session,expo,wall,fade,scale,unityshell]
>  DistroCodename: oneiric
>  DistroRelease: Ubuntu 11.10
>  DistroVariant: ubuntu
>  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
>  NonfreeKernelModules: nvidia
>  Package: compiz 1:0.9.6+bzr20110929-0ubuntu5vv1
>  PackageArchitecture: all
>  ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
>  Tags:  oneiric running-unity oneiric running-unity ubuntu
>  Uname: Lin...

Read more...

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (3.7 KiB)

Not sure how I can pull and apply the fix. Can you provide some quick
directions ?

On Sun, Jan 29, 2012 at 11:15 PM, Jason Smith <email address hidden> wrote:
> The linked branch should resolve the issue. Simply put there were a LOT
> of 0's in that list. The tracker should have been ignoring GUID 0 (its
> not valid and represents a client side texture) but was not accurately
> doing this.
>
> ** Branch linked: lp:~unity-team/nux/nux.fix-gradual-degrade
>
> ** Changed in: unity
>       Status: Confirmed => Fix Committed
>
> ** Changed in: unity
>   Importance: Undecided => Critical
>
> ** Changed in: unity
>     Assignee: (unassigned) => Jason Smith (jassmith)
>
> ** Changed in: unity
>    Milestone: None => 5.2.0
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Unity:
>  Fix Committed
> Status in “unity” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  after: ~30 percent.
>
>  This has been an issue since 11.04 for me on both my Intel i915 and
>  Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX,
>  both having the same issue). However, the nvidia machine is where it
>  really hurts, _always_ happening within a day or two, while the i915
>  machine is pretty reliable overall with certain instances of
>  degradation (used to be affected just as badly in 11.04).
>
>  I will attach two videos demonstrating behavior before and after.
>  ---
>  ApportVersion: 1.23-0ubuntu4
>  Architecture: amd64
>  CheckboxSubmission: 33c9cec13de798ee31ce4ea2f2cbd4df
>  CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
>  CompizPlugins: [core,detection,composite,opengl,decor,regex,winrules,compiztoolbox,animation,grid,vpswitch,snap,place,gnomecompat,resize,move,mousepoll,imgpng,workarounds,session,expo,wall,fade,scale,unityshell]
>  DistroCodename: oneiric
>  DistroRelease: Ubuntu 11.10
>  DistroVariant: ubuntu
>  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release ...

Read more...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Nice work all. But let's not get too far ahead of ourselves... as real testing is required to prove that it was this particular bug that was just fixed.

It's always possible that you're fixing a different bug, or more similar mistakes exist that also need fixing to resolve the bug.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Give me a few hours and I'll try to get the fix into ppa:vanvugt/unity

Revision history for this message
Michael Knap (michael-knap) wrote :
Download full text (3.5 KiB)

Thanks again Daniel ! I have already downloaded the bzr branch that
Jason linked to, but I'm having a hell of a time getting all the dev
packages needed to compile. Is there a better way to get all the dev
dependencies from the source code branch ?

Michael Knap

http://michaelknap.net
Instructor and Researcher
Mathematics and Controls Engineering
Center of Excellence in Information Systems
Tennessee State University

On Sun, Jan 29, 2012 at 11:52 PM, Daniel van Vugt <email address hidden> wrote:
> Give me a few hours and I'll try to get the fix into ppa:vanvugt/unity
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/888039
>
> Title:
>  Gradual degradation in desktop performance.
>
> Status in Unity:
>  Fix Committed
> Status in “unity” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  Over the span of 1-3 days I see my desktop consistently become more
>  sluggish. The functions most affected are window movement, file icon
>  movement, and sometimes window resizing. Other animations (such as
>  minimizing fades, switching desktops, expo mode) are not affected when
>  this degradation occurs. They remain smooth; however, I have let the
>  problem go on as long as to find out that eventually all desktop
>  animations/effects will degrade, it just takes a lot lot longer. I
>  find that my actual 3D gaming goes unaffected (though I have no data
>  to back that up, perhaps it does).
>
>  I have recorded the output of 'ps auxw' and have slowly watched the
>  VSZ and RSS memory columns creep upwards. A fresh compiz session will
>  see 675164 and 169860, respectively. After a day or two it will result
>  in as high as 878552 and 255664. I have attached a log output from an
>  hourly cron job (though I had suspended for a few days because of
>  travel).
>
>  After the degradation has occurred compiz will consistently use higher
>  CPU. Dragging a terminal window while watching top: before: ~10%,
>  after: ~30 percent.
>
>  This has been an issue since 11.04 for me on both my Intel i915 and
>  Nvidia (proprietary) machines (had an 8600 GT and upgraded to 560 GTX,
>  both having the same issue). However, the nvidia machine is where it
>  really hurts, _always_ happening within a day or two, while the i915
>  machine is pretty reliable overall with certain instances of
>  degradation (used to be affected just as badly in 11.04).
>
>  I will attach two videos demonstrating behavior before and after.
>  ---
>  ApportVersion: 1.23-0ubuntu4
>  Architecture: amd64
>  CheckboxSubmission: 33c9cec13de798ee31ce4ea2f2cbd4df
>  CheckboxSystem: 4ed15c40009aa6f7770f606350a390a2
>  CompizPlugins: [core,detection,composite,opengl,decor,regex,winrules,compiztoolbox,animation,grid,vpswitch,snap,place,gnomecompat,resize,move,mousepoll,imgpng,workarounds,session,expo,wall,fade,scale,unityshell]
>  DistroCodename: oneiric
>  DistroRelease: Ubuntu 11.10
>  DistroVariant: ubuntu
>  InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
>  NonfreeKernelModules: nvidia
>  Package: compiz 1:0.9.6+bzr20110929-0ubuntu5vv1
>  PackageArchitecture: all
>  ProcVersionSignature: Ubu...

Read more...

Jason Smith (jassmith)
Changed in unity (Ubuntu):
status: Confirmed → Fix Committed
importance: Undecided → Critical
assignee: nobody → Jason Smith (jassmith)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The branch it was committed to was Nux 2.x for precise. Even if you get it to build it won't be compatible with Unity 4.x in oneiric (which uses Nux 1.x)

I am backporting the fix to Nux 1.x and oneiric. But have to do it by hand, which is slow and error-prone. Please be patient.

Revision history for this message
Jason Smith (jassmith) wrote :

If new bugs are found, please open a new bug report. Do not re-open this one as it has scoped down to a particular bug in Nux. It would be a disservice to any other defects to tack them to the bottom of this report.

description: updated
Revision history for this message
Michael Knap (michael-knap) wrote :

I will wait patiently until tomorrow. Thank you again so much. What can I do to help out more (not necessarily with this bug but in general on launchpad/ubuntu)?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Michael, it would be very helpful to have another person reviewing and triaging these bugs:

https://bugs.launchpad.net/ubuntu/+source/compiz/
https://bugs.launchpad.net/ubuntu/+source/unity/

There are a lot, but you may be able to find and cross some off as duplicates. Others may be so old they are either fixed already (Fix Released) or are unreproducible. For more instructions, see:

https://wiki.ubuntu.com/Bugs/HowToTriage

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Finished backporting Jason's fix to oneiric. It is building and will become available in the next few hours in:
    ppa:vanvugt/unity
You will know you've got the fix when your nux packages get upgraded to: 1.16.0-0ubuntu1.1vv1

If everyone is happy that the fix works for them, I will propose it for an official oneiric update.

Revision history for this message
Michael Knap (michael-knap) wrote :

I will be testing Daniel's ppa over the next few days. I will report back here on the tests. Also, I will read the HowToTriage, and see what I can do with those bugs.

Revision history for this message
Michael Knap (michael-knap) wrote :

I've installed your packages Daniel, and I'm getting some other instability. compiz or unity restarts or compiz/unity dies without a restart. I haven't done any debugging yet on these issues, but I will continue to look into it.

What is the correct course of action here ?

Revision history for this message
Jason Smith (jassmith) wrote :

its unlikely any instability is being introduced by this bug. Follow normal bug reporting procedure.

Revision history for this message
Timothy Stratton (tfstratton2007) wrote :

Awesome job on this guys!!! I've been waiting to see the resolution of this bug! Michael, great work on finding the increasing CPU usage over time! not sure if anyone would have caught that! Awesome job and great initiative!

Revision history for this message
Michael Knap (michael-knap) wrote :

Just a quick report: Jason's fix and Daniel's packages appear to be working wonderfully ! Over the past 24 hours, compiz cpu usage has not climbed and remains steady <=4% on both of the machines I work on which exhibited this problem.

Thank You.

Changed in unity:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.4 KiB)

This bug was fixed in the package unity - 5.2.0-0ubuntu1

---------------
unity (5.2.0-0ubuntu1) precise; urgency=low

  * New upstream release.
    - Unity needs a way to switch (tab) between windows on current workspace
      (LP: #863399)
    - compiz crashed with SIGSEGV in BamfLauncherIcon::NameForWindow()
      (LP: #865840)
    - Gradual degradation in desktop performance. (LP: #888039)
    - compiz (unity) crashes with SIGSEGV when a window is minimized.
      (LP: #918329)
    - FavoriteStore external change support (LP: #681503)
    - Launcher - Make Launcher left of screen reveal more responsive and less
      prone to false positives (LP: #765819)
    - Window auto-maximise functionality should be disabled on monitors with a
      resolution above 1024 x 600 (LP: #797808)
    - Dash: very high latency responding to input (LP: #828582)
    - Dash - Behaviour of the 'All' button in the Dash filters broken in
      several ways (LP: #841864)
    - alt-tab - The app title in the top left of the top bar should change as
      the alt-tab focus changes (LP: #855516)
    - Keyboard shortcut - Add keyboard shortcut hint overlay that is displayed
      when a user presses and holds the Super key (LP: #855532)
    - Unity crashes when started in an environment without utouch support
      (LP: #860707)
    - Dash - Remove Dash Home shortcut icons (LP: #885738)
    - Dash - Most Frequently Used apps change to Recently Used, without
      Launcher favorites (LP: #893214)
    - Should have a launcher on every monitor (LP: #915944)
    - Launcher autohide behaviour on multi-monitor (LP: #915946)
    - the unity wrapper should kill compiz before restarting it (LP: #919132)
    - Launcher - Implement workspace/launcher cross interactions (LP: #690143)
    - Application icons should only display windows from the current workspace
      in the window spread (LP: #689733)
    - Notification area ("system tray") missing when using dual monitors of
      different sizes, with their bottoms aligned (LP: #778256)
    - Clicking Nautilus launcher icon fails to open a Nautilus file explorer
      window when copying a file and all other Nautilus windows are closed /
      bamf should skip the taskbar (LP: #784804)
    - Dash - the search box is not aligned correctly relative to the Launcher
      BFB button (LP: #838904)
    - Dash - A expand/collapse arrow is missing from all the filter category
      headers (LP: #841870)
    - Dash - the filter buttons should not have a mouse over state
      (LP: #838901)
    - Dash - the "Filter results" text is the wrong size, wrong font weight,
      and aligned incorrectly in both the vertical and horizontal axis
      (LP: #863240)
    - Add SUPER+TAB switching mode that enables the user to switch
      applications via the Launcher (LP: #891620)
    - Software Centre - automatically add app icon to launcher (LP: #761851)
    - Compiz add transparency to titlebar along with the panel (LP: #912682)
    - The search box is too opaque and dark (LP: #913717)
    - Dash - Make statefulness of Dash Home and Dash Lenses consistent
      (LP: #914759)
    - Unity 5.0: "All" button for filters render as "..." (LP: #91...

Read more...

Changed in unity (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I'm guessing by the silence that the fix seems to be working for everyone?...

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I'm thinking so!

<3 you guys.

Revision history for this message
Rocko (rockorequin) wrote :

I also think it is working great! (I'm using libnux 1.16.0-0ubuntu1.1vv1 and unity 4.28.0-0ubuntu2vv2 which look like the latest versions from ppa:vanvugt/unity.)

Revision history for this message
Joar Jegleim (joar-jegleim) wrote :

I'm still having some issues, I had some performance drop (as in very lag'y desktop) on thursday or friday before the weekend, and I'm seeing some symptoms again now.

I'm thinking I may have an other bug if no one else see any regression after last update .

I'm having trouble reporting in detail since my work days are pretty hectic, and when I hit performance problems I seldom have time to look into it 'cause I'm in the middle of something and just have to reboot and pick up where I left .
I'm working mainly through terminals, I've got 6 virtual desktops, 1 with chromium and firefox, 1 with thunderbird and the rest is filled with terminator + I got xchat, spotify and a terminator on my second monitor 'always on visible workspace' .

Revision history for this message
Ben Gamari (bgamari) wrote :

Joar,

Yes, you are likely seeing another bug. If you are still having problems the best way to proceed will be to open a new bug and attach a perf profile as was done to pinpoint this one.

Revision history for this message
AndreK (andre-k) wrote :

"dpkg -s unity" returns :
....
version: 4.28.0-0ubuntu2
...

Does this mean I did not get the update yet ? 5.2.0 seems so far away ?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

AndreK, you appear to not have the fix installed. You need to be using ppa:vanvugt/unity to get the fix for oneiric;
https://launchpad.net/~vanvugt/+archive/unity

Revision history for this message
AndreK (andre-k) wrote :

I suspected that - when does "fix released" actually mean it's an actual update in the standard repository ? when is it expected to be there. ?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The fix is in Unity 5.2.0 as per comment #117, so it will be in 12.04 when that gets Unity 5.2. A fix has not been proposed for 11.10 yet. I said I would do so when the fix in my PPA has been sufficiently tested. Although, please don't shoot the messenger... I'm just doing this because I care.

I agree that Ubuntu's handling of Fix Released is very confusing in the least. You have no idea if Fix Released means the fix is available in an actual GA release, or is only queued up to go into the next alpha release, or if it will _ever_ be available in an update for an existing release. This problem is discussed in bug 163694, bug 827912, bug 151925, and probably many others too.

Revision history for this message
Lem (lem-jjr) wrote :

I'm not sure exactly where I should report it, but Daniel with the latest version of compiz/unity in your PPA on Ubuntu 11.10, I can run OilRush fullscreen at virtually the same speed as a non-composited desktop, provided I use Unredirect Fullscreen Windows (enabled via ccsm). The composited desktop is fast and responsive too.

Well done to you and others who have fixed this up. Will these performance settings be the default for 12.04? The last few Ubuntu releases have needed tweaking to get decent performance out of the box :( It's harder now that CCSM is outdated and can break the compiz configuration.

(my config: Phenom II X4 955, GTX560Ti 1Gb, 1920x1200, nvidia binary driver, Ubuntu 11.10 AMD64)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes, I do believe all the performance-related fixes in my PPAs will be in Ubuntu 12.04.

Revision history for this message
Jason Smith (jassmith) wrote :

I am confirming that all the perf fixes will be in 12.04. probably some extra ones too. I am tired of hearing about slow perf and finally have some free cycles to do something about it. Mmmm yes optimization goodness here I come.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Jason, I don't suppose you could improve the fix for this bug to use std::set instead of std::vector? Or even remove the code completely in Nux 2.0 as you mentioned in the MP? :)

Omer Akram (om26er)
Changed in unity (Ubuntu Oneiric):
importance: Undecided → High
status: New → Confirmed
Omer Akram (om26er)
Changed in unity (Ubuntu Oneiric):
status: Confirmed → Triaged
Omer Akram (om26er)
description: updated
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Merged into lp:nux/1.0 at revision 499

Changed in unity (Ubuntu Oneiric):
status: Triaged → Fix Committed
assignee: nobody → Daniel van Vugt (vanvugt)
Revision history for this message
Sebastien Bacher (seb128) wrote :

Uploaded: https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=nux

Subscribed ubuntu-sru as well, somebody from that team will review and approve the upload next and update the bug asking for testing when that happens (probably next week though since it's friday)

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Hello Chauncellor, or anyone else affected,

Accepted nux into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Revision history for this message
Magnetizer (magnetizer) wrote :

Hi everybody,

Daniel, I have your used your unity PPA for some time now (+/- 2 weeks).

My first impression was that it solved the problem, but after some hours the bug just returned.

Window movement gets very slow after using unity for some time (some hours max). When it occurs I can see all windows stopping to refresh until I stop moving the window. This is most visible if I play a video in one window and try to move this window (or any other window) at the same time.

The moment I stop moving the window the video refreshes and plays again and the window moves to the new position. During all the time, the sound of the video continues normally.

If I use the 2D version of unity or XFCE, LXDE everything works normal. It also "works" if I move the window very slowly. I can see some refreshes while moving the window but the video stutters.

There are a lot of bugs out there reporting "bad performance" of unity in Ubuntu 11.10, so it is difficult to decide which is the right bug report.

Right now, I do not know which possible solution to try next. From what I saw this far this bug report matched my problem the most but unfortunately it did not solve the problem.

Does anyone have suggestions for the next step?

Thanks!

Revision history for this message
Jason Smith (jassmith) wrote :

There is an unrelated bug dealing with an improper freeing in unity that resulted in memory corruption. This memory corruption results in behavior similar to what you described. A fully up to date unity without PPA's will resolve the issue.

Revision history for this message
Magnetizer (magnetizer) wrote :

Thanks Jason, I will try updating unity to the newest version available without the PPA from Daniel.

Do you happen to know the ID of the bug you are describing?

Revision history for this message
Maciej Dragan (maciej-dragan) wrote :

Hi, I'm using Daniel's PPA for few days now and my Unity became usable again but I'm experiencing the same problem as Andre. I can't find any updates for both unity and nux in oneiric-proposed. Was it released, or the fix is only for 12.04?

dpkg -s nux-tools
... 1.16.0-0ubuntu1.1+fixlp892443-ppa1~oneiric1 ...
dpkg -s unity
... 4.28.0-0ubuntu2 ...

Revision history for this message
Magnetizer (magnetizer) wrote :

Hi Jason & Maciej,

I purged Daniel's PPA and tried ppa:unity-team/staging in order to apt-get update && apt-get-upgrade to the latest unity version. Strange enough it did not update my unity version which is still 4.28.0.

What did I do wrong?

I also tried the alpha 2 of Ubuntu 12.04 for some time. It uses unity 5.4.0 and it seems that it is much snappier than my current desktop.

Any ideas?

Revision history for this message
Omer Akram (om26er) wrote :

staging ppa is for precise only.

Revision history for this message
Magnetizer (magnetizer) wrote :

Omer, thanks.

Are you sure of explanation?

I followed

http://www.omgubuntu.co.uk/2012/01/how-to-install-unity-5-0-in-ubuntu-11-10/

where it says to install ppa:unity-team/staging

But indeed, it did not work... ;-)

What are my alternatives? Do I need to compile unity 5.4 myself or do you happen to know a .deb file out there?

Revision history for this message
Omer Akram (om26er) wrote :

Andre, you can't compile 5.4 simply as that would need quite a few other things like compiz, nux libunity and prolly a few others as well. You could try Precise Pangolin Beta-2 set to release thursday, 1st of March.

Revision history for this message
Magnetizer (magnetizer) wrote :

Omer, thanks, I get it.

I read about it and did not found a solution. I tried the Alpha2 of Precise Pangolin which is indeed a lot snappier.

I will try the Beta-2 next week. If it is stable enough I will run it. Otherwise I'll just wait for the final release. In fact, unity 4 in Ubuntu 11.10 is workable, but just not very snappy after some time. I still have XFCE and LXDE as alternatives..;-)

Thanks for the explanation.

Changed in unity (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

nux (1.16.0-0ubuntu1.2) oneiric-proposed; urgency=low

  * NuxGraphics/RunTimeStats.cpp:
    - Gradual degradation in desktop performance. (LP: #888039)
 -- Omer Akram <email address hidden> Thu, 09 Feb 2012 20:56:12 +0500

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

And FYI, the fix for this appears in precise in nux version 2.2.0-0ubuntu1. Though it wasn't mentioned in the changelog...

nux (2.2.0-0ubuntu1) precise; urgency=low

  * New upstream release.
    - Dash - Behaviour of the 'All' button in the Dash filters broken in
      several ways (LP: #841864)
    - Launcher, Spread - Clicking on a Launcher app icon a second time to
      close a spread is broken (LP: #893670)
    - launcher not hiding in one design-specified case (LP: #919162)
    - compiz crashed with SIGSEGV in
      nux::GridHLayout::KeyNavIterationRowOrder() (LP: #916088)
  * Cherry-pick an additional fix for boot time

 -- Didier Roche <email address hidden> Fri, 03 Feb 2012 11:35:48 +0100

Revision history for this message
Saúl Romero (spacetree) wrote :

I'm experiencing the same problem in Precise, with a Dell XPS 15.

In my case, degradation is noticeable from the moment I open an application. Also, I noticed today (as im writing this) that the performance goes smoother witouth t he power connected to the laptop, working on battery power. My guess is that the problem is in the interaciton Nvidia-Unity.

Any insights?

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Saul, You should look around for a bug report regarding your issue. If you cannot find one then please open a new bug report by running 'ubuntu-bug compiz'.

This report has been resolved so it's not much use.

Revision history for this message
Brian Murray (brian-murray) wrote :

The verification of the fix for this bug in oneiric-proposed never occurred so I am setting the task back to Fix Committed. It'd be great if somebody could test the package from -proposed so we can release the fix.

Changed in unity (Ubuntu Oneiric):
status: Fix Released → Fix Committed
Revision history for this message
Pushkin (kovshovik-alexandr) wrote :

It looks like this problem is finally resolved and released in Ubuntu Quantal: http://www.ubuntuupdates.org/bugs?package_name=libnux-3.0-0

This Bug is a very entertaining read: thank you Chauncellor for detailed problem description.

Thank you, Daniel van Vugt, for keeping cool at all times.

Revision history for this message
Brian Murray (brian-murray) wrote : Verification still needed

The fix for this bug has been awaiting testing feedback in the -proposed repository for oneiric for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

tags: added: removal-candidate
Revision history for this message
Rocko (rockorequin) wrote :

I'm not using Oneiric any more, but Quantal is perfoming well for me (apart from unity-compiz hanging and needing restarting sometimes, but I suspect that's an intel driver issue). Has Quantal got the same fix as Oneiric? The only times I've noticed performance degradation in Quantal is after an intel driver crash.

Revision history for this message
Brian Murray (brian-murray) wrote :

The version of nux in oneiric-proposed has been removed as this bug report was not verified in a timely fashion.

Changed in unity (Ubuntu Oneiric):
status: Fix Committed → Triaged
tags: removed: verification-needed
tags: removed: removal-candidate
Changed in unity (Ubuntu Oneiric):
status: Triaged → Won't Fix
Ron Karoles (rkaroles)
Changed in unity (Ubuntu):
assignee: Jason Smith (jassmith) → Ron Karoles (rkaroles)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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