[sugar] composite memory usage [was Re: frame auto-visibility configuration]
Tomeu Vizoso
tomeu at tomeuvizoso.net
Wed Sep 24 15:11:36 EDT 2008
On Wed, Sep 24, 2008 at 8:56 PM, Erik Garrison <erik at laptop.org> wrote:
> 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.
Bernie has talked about some wm hints that can be set on windows so
they get unredirected and thus their offscreen pixmaps released. Not
sure if matchbox would support them, though.
Related with all this is the decision to switch window managers.
Perhaps keeping redirected just the two activities on top of the stack
plus the desktop window may be enough? I think that would mean a
constant 12MB, approx.
Regards,
Tomeu
More information about the Sugar
mailing list