[sugar] composite memory usage [was Re: frame auto-visibility configuration]

[Erik Garrison]

On Wed, Sep 24, 2008 at 07:51:30PM +0200, Tomeu Vizoso wrote:
> On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva <hoboprimate at gmail.com> wrote:
> > Wow, just tried Erik's instructions for using xcompmgr, and it's
> > amazing how swift the frame slides, and how I don't see any screen
> > redraws. The experience is totally more fluid. Does it degrade overall
> > performance? If not much, and if that performance degradation could be
> > recovered in another area in Sugar (general performanfe improvements),
> > I'd vote for this to exist in joyride and even part of future stable
> > builds.
> 
> AFAIK, the only tradeback (and the reason why it hasn't been activated
> yet) is that we must pay composition with increased memory usage.
> Composition basically saves us unnecessary redraws by keeping in
> memory copies of the windows contents.
> 
> Martin Dengler did back in March an excellent job quantifying this tradeback:
> 
> http://lists.laptop.org/pipermail/sugar/2008-March/004718.html

Using similar methods (ps_mem.py), I get roughly the same results.

I run ps_mem.py at five places, before and after enabling composite with
0 to 4 activites running (Chat, Paint, Write, and Browse).  (I get ten
files named {before,after}_*_activity, and then grep them to make
comparitive claims.)


We can see that Activities use about the same amount of memory before
and after the change:


e.g. Paint:

before_1_activity:  9.3 MiB +   4.2 MiB =  13.5 MiB     Paint <65be2c3b
before_2_activity:  9.2 MiB +   3.1 MiB =  12.3 MiB     Paint <65be2c3b
before_3_activity:  9.4 MiB +   2.5 MiB =  11.9 MiB     Paint <65be2c3b
before_4_activity:  9.4 MiB +   2.1 MiB =  11.5 MiB     Paint <65be2c3b

after_1_activity:  9.3 MiB +   4.2 MiB =  13.5 MiB      Paint <eb84d7a4
after_2_activity:  9.3 MiB +   3.1 MiB =  12.4 MiB      Paint <eb84d7a4
after_3_activity:  9.2 MiB +   2.5 MiB =  11.7 MiB      Paint <eb84d7a4
after_4_activity:  9.2 MiB +   2.1 MiB =  11.3 MiB      Paint <eb84d7a4


e.g. Write:

before_3_activity: 19.4 MiB +   2.8 MiB =  22.2 MiB     Write <d2756bab
before_4_activity: 19.4 MiB +   2.4 MiB =  21.8 MiB     Write <d2756bab

after_3_activity: 19.4 MiB +   2.8 MiB =  22.2 MiB      Write <d863e164
after_4_activity: 19.4 MiB +   2.4 MiB =  21.8 MiB      Write <d863e164


However, there is an obvious memory difference between the two
situations:

                                 [ total memory usage ]

before_0_activity-                         86.4 MiB
before_1_activity-                         98.0 MiB
before_2_activity-                        126.6 MiB
before_3_activity-                        146.2 MiB
before_4_activity-                        154.9 MiB

after_0_activity-                         88.5 MiB
after_1_activity-                        109.8 MiB
after_2_activity-                        138.0 MiB
after_3_activity-                        162.7 MiB
after_4_activity-                        173.2 MiB

When composition is enabled, we used 18.3 MiB more to run the same 4
activities.


Following Martin Dengler's lead, we discover that this memory is mostly
used by the X server:

bash-3.2# grep Xorg before*
before_0_activity:  3.1 MiB + 390.5 KiB =   3.5 MiB     Xorg
before_1_activity:  3.2 MiB + 430.0 KiB =   3.6 MiB     Xorg
before_2_activity:  3.4 MiB + 420.0 KiB =   3.9 MiB     Xorg
before_3_activity:  3.7 MiB + 509.5 KiB =   4.2 MiB     Xorg
before_4_activity:  3.7 MiB + 507.5 KiB =   4.2 MiB     Xorg

bash-3.2# grep Xorg after*
after_0_activity:  3.0 MiB + 342.5 KiB =   3.3 MiB      Xorg
after_1_activity: 10.9 MiB + 445.0 KiB =  11.4 MiB      Xorg
after_2_activity: 13.1 MiB + 425.5 KiB =  13.5 MiB      Xorg
after_3_activity: 18.0 MiB + 506.0 KiB =  18.5 MiB      Xorg
after_4_activity: 19.9 MiB + 504.0 KiB =  20.4 MiB      Xorg

A little under 15 MiB of increase.

> 
> I'd vote for activating composition ASAP once we have a 9.1 joyride
> branch and see how we can find the sweetest spot between speed and
> memory usage.
> 

I agree.

There also may be bugs which we need to shake out.  If this is a feature
we know we want for 9.1, the sooner we start testing the better.

Erik