Re: Extreme memory usage for gnome-panel related apps

[Andrew Cowie]

On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> And more generally, to have one VM per language type, rather than per
> app.

I suppose one problem you'd have to deal with is the tendency for a
segfault to take out the entire VM.

The C [only] programmers reading this are, of course, all used to
writing programs that can crash. Certainly we don't want this to happen,
but when we do something wrong, we get a nice segfault and fire up GDB
on the aborted program to start debugging it. The rest of your desktop
keeps running. Yeay.

Because a {pyGTK, java-gnome, gtk#, whatever} application is of course
linking against the native GTK library, when you get a crash in GTK the
*program* you are crashing is the {Python VM, Java VM, ...} 

If you were to try and get all the programs running in a managed
language into a single process, then we'd have to figure out how to not
take out all the other applications that happen to be running in that VM
when your buggy thunders in.

[Java, for example, *is* capable of running _many_ disparate
programs - infrastructure like separate ClassLoaders and fairly
rigorous visibility and security policy between classes provides
for this, and you see it in production use all the time in
Servlet containers, enterprise application servers etc - and it
all works quite well **provided** they are all written in pure
Java and make no native calls]

People across the computing spectrum have been tantalized by this
prospect for a long time, but I get the impression that everyone gets
hung up on the "what do you do when a native library call crashes your
VM" issue.

Otherwise, wouldn't it be wonderful to have a single Python VM, a single
Java VM, etc. Shit, make it a kernel module.

Oh well.

AfC
Bangalore



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Rob Taylor]

jamie wrote:
> On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
>> On Sun, 2007-12-02 at 15:36 +, jamie wrote:
>>
>>> Vala of course - http://live.gnome.org/Vala
>> Rewriting every application in another language isn't the answer for
>> resource usage.  Not that Vala is bad, on the contrary it seems nice for
>> some use cases, but in terms of engineering effort it would be far
>> easier to rework various Python applications like deskbar,sealert etc.
>> to run in a single Python process.  
>>
>> And more generally, to have one VM per language type, rather than per
>> app.
>>
> 
> so if one app dies your entire desktop dies too?
> 
> As far as python goes the big culprit is PyGTK AFAICT - it seems to
> contribute a huge amount of bloat
> 
> A better way may be to have the front end of say deskbar in c/c++/vala
> and embed python for the existing plugins (which do not use pygtk
> AFAICT)
> 
> Python works best when its embedded and shows its real utility in apps
> like Epiphany and Rhythmbox but I cant say Im impressed by standalone
> GTK python apps...


Here is the main problem with pygtk's memory usage and startup time (as
I understand it). It's well understood, but requires ABI breakage:

http://bugzilla.gnome.org/show_bug.cgi?id=346946

Maybe it can get fixed with pybank ;)

A bigger problem is python's memory usage in general, that seems to be a
lot less well understood. http://bugs.python.org/issue1123430 is
informative.

Thanks,
Rob
-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Johan Dahlin]

Mikkel Kamstrup Erlandsen wrote:
> On 02/12/2007, *Colin Walters* <[EMAIL PROTECTED] 
> > wrote:
[..]
> So how would this be done? One Python thread to run each applet in? 
> Assuming this then it is pretty far from feasible. Python and GTK 
> threading is not exactly the nicest thing to work with. The slightest 
> glitch and all apps in the loop would block.
> 

A system-wide daemon such as python-launcher would probably do it.
It essentially runs python and pygtk once and then you'd fork all further
processes from it, that way you only have to load pygtk once per session.

Johan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Xavier Bestel]

Le dimanche 02 décembre 2007 à 20:52 +, Alan Cox a écrit :
> Taking out the commonly used python apps and replacing them with compiled
> code would be an even bigger performance and size leap.

How about adding to that "forking after having initialized all
libraries" ?

Xav


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen]

On Sun, 2007-12-02 at 22:49 +, Alan Cox wrote:
> > (FWIW, personally, I'd like to see all of our service daemons (g-p-m,
> > g-v-m, pk-update-client, etc.) all sharing the same process space.
> > Things like that.)
> 
> With a kernel hat on do you have a specific reasons for that ? Is there
> stuff you gain or is this primarily about memory usage of non shared
> objects ?

I was thinking only performance wins: Most of these daemons poke system
components through D-Bus and listen for async events; by pooling the
traffic onto the same D-Bus connection some overhead may be saved
including only having to wake up a single process, only set up a single
connections and so forth.

Thinking more about it I'm not sure it matters much...

Then there's also the social aspect; if all our service daemons are in
the same process / code base (and perhaps written in similar ways using
similar patterns) it becomes easier to figure out how to add new
functionality. Also, the individual daemons can use non-IPC constructs
to talk to each other; for example there's a bunch of IPC between the
screensaver and the power manager; that could all be local [1]. Similar,
the volume manager refuses to mount anything if the screen is locked
[2].

 David

[1] : though there's the complication that the screensaver needs to be
more secure than most other service daemons. Then again it could use a
helper to do the critical bits like locking the screen (if it doesn't
already).

[2] : to prevent an attacker from walking up to a locked machine and
taking control of the machine by using a carefully crafted USB stick
that will cause a buffer over flow in a file system driver.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Alan Cox]

> (FWIW, personally, I'd like to see all of our service daemons (g-p-m,
> g-v-m, pk-update-client, etc.) all sharing the same process space.
> Things like that.)

With a kernel hat on do you have a specific reasons for that ? Is there
stuff you gain or is this primarily about memory usage of non shared
objects ?

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Hubert Figuiere]

On Sun, 2007-12-02 at 13:27 -0800, Ethan Osten wrote:
> 
> Personally, I hate coding in C - I have better things to do with my
> time
> than to deal with things I don't really have to deal with. And I know
> there are a lot of people like me, or else PyGTK etc. wouldn't be so
> popular. "Go back to C" just isn't an acceptable option.

You can use C++ :-)
It brings speed comparable to C, very good interoperability with
existing C code, compile time type checking, easy to use class system
(compared to GObject), and good C++ binding (Gtkmm is even designed to
be interoperable).

Granted than the overall resistance from GNOME contributors does not
help (most of it being pure FUD due to lack of knowledge).



Hub


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ethan Osten]

On Sun, 2007-12-02 at 20:42 +, jamie wrote:
> On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> > On Sun, 2007-12-02 at 15:36 +, jamie wrote:
> > 
> > > Vala of course - http://live.gnome.org/Vala
> > 
> > Rewriting every application in another language isn't the answer for
> > resource usage.  Not that Vala is bad, on the contrary it seems nice for
> > some use cases, but in terms of engineering effort it would be far
> > easier to rework various Python applications like deskbar,sealert etc.
> > to run in a single Python process.  
> > 
> > And more generally, to have one VM per language type, rather than per
> > app.
> > 
> 
> so if one app dies your entire desktop dies too?
> 
> As far as python goes the big culprit is PyGTK AFAICT - it seems to
> contribute a huge amount of bloat
> 
> A better way may be to have the front end of say deskbar in c/c++/vala
> and embed python for the existing plugins (which do not use pygtk
> AFAICT)

If PyGTK is bloated, shouldn't the answer be to fix PyGTK rather than to
rewrite every piece of code using it?

Personally, I hate coding in C - I have better things to do with my time
than to deal with things I don't really have to deal with. And I know
there are a lot of people like me, or else PyGTK etc. wouldn't be so
popular. "Go back to C" just isn't an acceptable option.

Ethan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen]

On Sun, 2007-12-02 at 16:03 -0500, Colin Walters wrote:
> On Sun, 2007-12-02 at 21:56 +0100, Mikkel Kamstrup Erlandsen wrote:
> 
> > 
> > So how would this be done? One Python thread to run each applet in?
> 
> No, every applet runs in the same thread, using the same main loop.
> If the applet is written correctly, it does everything that potentially
> blocks (say retrieving data over HTTP) already in another thread or
> otherwise asynchronously.  Thus it would be safe to have multiple
> programs sharing a mainloop.

Well, at least that's one way to do it. What you are proposing is
essentially cooperative multitasking. (Not saying it's necessarily bad)

(This also just reminds me of how awful it is to use multiple web
applications (flickr, facebook, gmail) in the same browser process since
each of them slows down the others considerably.)

David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Colin Walters]

On Sun, 2007-12-02 at 21:56 +0100, Mikkel Kamstrup Erlandsen wrote:

> 
> So how would this be done? One Python thread to run each applet in?

No, every applet runs in the same thread, using the same main loop.
If the applet is written correctly, it does everything that potentially
blocks (say retrieving data over HTTP) already in another thread or
otherwise asynchronously.  Thus it would be safe to have multiple
programs sharing a mainloop.

>  Assuming this then it is pretty far from feasible. Python and GTK
> threading is not exactly the nicest thing to work with. The slightest
> glitch and all apps in the loop would block. 

Yes, it does mean that a bug in one applet would potentially affect
others.  But the applet was already buggy to begin with, because its UI
already blocked.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen]

On Sun, 2007-12-02 at 15:51 -0500, Colin Walters wrote:
> On Sun, 2007-12-02 at 15:39 -0500, David Zeuthen wrote:
> > On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> > > And more generally, to have one VM per language type, rather than per
> > > app.
> > 
> > There's a lot of security models that break down if everything is tied
> > to a single process. 
> 
> I'm not sure why people are going from "Unify a few Python programs into
> one VM" into "We must only have 3 processes total!".
> 
> If some application was security sensitive, we could keep it separate.  

That's a fine goal but not really how I (and apparently others) read
your original message. 

(FWIW, personally, I'd like to see all of our service daemons (g-p-m,
g-v-m, pk-update-client, etc.) all sharing the same process space.
Things like that.)

> But fundamentally right now the desktop is still one security domain,
> and I don't see that changing in the near future.

http://lists.freedesktop.org/archives/xorg/2007-November/030631.html

That said, it's probably a few years out before things like password
dialogs a) cannot be poked by e.g. the browser; b) can be poked by the
a11y tools. Bunch of other use cases too (browser, email in confined
domains). But it's something that is badly needed and XACE-SELinux
brings us one step closer.

> > Not to mention a bunch of other problems. It's
> > probably better to just fix the VM's.
> 
> Far harder - and I think it would likely require language semantics to
> change, in particular for Python.
> 
> Having one VM for Python applets would not be rocket science.  Someone
> just needs to spend the few days on it, and get patches to use it
> upstreamed.

Sure, but keep in mind what you're suggesting is a stop-gap fix that
will hide the real problems (per-process overhead), introduce weird and
hard to fix bugs. You know what happens to stop-gap fixes? They become
mainstream and people will never fix the real problem... 

Funny enough, it's also sometimes easier to fix root problems than to
introduce a bunch of stop-gap fixes.

 David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mikkel Kamstrup Erlandsen]

On 02/12/2007, Colin Walters <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 2007-12-02 at 15:39 -0500, David Zeuthen wrote:
> > On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> > > And more generally, to have one VM per language type, rather than per
> > > app.
> >
> > There's a lot of security models that break down if everything is tied
> > to a single process.
>
> I'm not sure why people are going from "Unify a few Python programs into
> one VM" into "We must only have 3 processes total!".
>
> If some application was security sensitive, we could keep it separate.
>
> But fundamentally right now the desktop is still one security domain,
> and I don't see that changing in the near future.
>
> > Not to mention a bunch of other problems. It's
> > probably better to just fix the VM's.
>
> Far harder - and I think it would likely require language semantics to
> change, in particular for Python.
>
> Having one VM for Python applets would not be rocket science.  Someone
> just needs to spend the few days on it, and get patches to use it
> upstreamed.


So how would this be done? One Python thread to run each applet in? Assuming
this then it is pretty far from feasible. Python and GTK threading is not
exactly the nicest thing to work with. The slightest glitch and all apps in
the loop would block.


Cheers,
Mikkel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Alan Cox]

> But fundamentally right now the desktop is still one security domain,
> and I don't see that changing in the near future.

The desktop is quite a few security domains. Mail clients handle
certificates and dangerous remote content, other tools render untrusted
content like PDF, while the desktop panel probably deals in little more
dangerous than weather reports.
> 
> > Not to mention a bunch of other problems. It's
> > probably better to just fix the VM's.
> 
> Far harder - and I think it would likely require language semantics to
> change, in particular for Python.
> 
> Having one VM for Python applets would not be rocket science.  Someone
> just needs to spend the few days on it, and get patches to use it
> upstreamed.

For applets it would be a huge help and I agree not be a security issue.
More generally it would make SELinux rules harder to get tight.

Taking out the commonly used python apps and replacing them with compiled
code would be an even bigger performance and size leap.

Alan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Colin Walters]

On Sun, 2007-12-02 at 15:30 -0500, Hubert Figuiere wrote:
> > And more generally, to have one VM per language type, rather than per
> > app.
> 
> So GNOME should be turned into a single address space with the kernel
> and X11.

I'm trying to suggest a solution to address the complaints about memory
usage that would be implementable in a fairly straightforward manner,
still allowing people to use the applications as they currently are.

If people have positive things to say, that would be useful.  I don't
think flippant quips like this ever helped anything.





___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Colin Walters]

On Sun, 2007-12-02 at 15:39 -0500, David Zeuthen wrote:
> On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> > And more generally, to have one VM per language type, rather than per
> > app.
> 
> There's a lot of security models that break down if everything is tied
> to a single process. 

I'm not sure why people are going from "Unify a few Python programs into
one VM" into "We must only have 3 processes total!".

If some application was security sensitive, we could keep it separate.  

But fundamentally right now the desktop is still one security domain,
and I don't see that changing in the near future.

> Not to mention a bunch of other problems. It's
> probably better to just fix the VM's.

Far harder - and I think it would likely require language semantics to
change, in particular for Python.

Having one VM for Python applets would not be rocket science.  Someone
just needs to spend the few days on it, and get patches to use it
upstreamed.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[jamie]

On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> On Sun, 2007-12-02 at 15:36 +, jamie wrote:
> 
> > Vala of course - http://live.gnome.org/Vala
> 
> Rewriting every application in another language isn't the answer for
> resource usage.  Not that Vala is bad, on the contrary it seems nice for
> some use cases, but in terms of engineering effort it would be far
> easier to rework various Python applications like deskbar,sealert etc.
> to run in a single Python process.  
> 
> And more generally, to have one VM per language type, rather than per
> app.
> 

so if one app dies your entire desktop dies too?

As far as python goes the big culprit is PyGTK AFAICT - it seems to
contribute a huge amount of bloat

A better way may be to have the front end of say deskbar in c/c++/vala
and embed python for the existing plugins (which do not use pygtk
AFAICT)

Python works best when its embedded and shows its real utility in apps
like Epiphany and Rhythmbox but I cant say Im impressed by standalone
GTK python apps...

jamie


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen]

On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> And more generally, to have one VM per language type, rather than per
> app.

There's a lot of security models that break down if everything is tied
to a single process. Not to mention a bunch of other problems. It's
probably better to just fix the VM's.

 David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Hubert Figuiere]

> And more generally, to have one VM per language type, rather than per
> app.

So GNOME should be turned into a single address space with the kernel
and X11.


Hub

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Colin Walters]

On Sun, 2007-12-02 at 15:36 +, jamie wrote:

> Vala of course - http://live.gnome.org/Vala

Rewriting every application in another language isn't the answer for
resource usage.  Not that Vala is bad, on the contrary it seems nice for
some use cases, but in terms of engineering effort it would be far
easier to rework various Python applications like deskbar,sealert etc.
to run in a single Python process.  

And more generally, to have one VM per language type, rather than per
app.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Jürg Billeter]

On Sun, 2007-12-02 at 17:20 +0100, Mark wrote:
> > for now it cross compiles into c but its a mistake to assume its just
> > syntactic sugar!
> 
> So that means that (for now) it is "syntatic sugar" and is basically
> c. so the compiled program has the memory and speed advantages of c.

The fact that valac compiles to C code should mostly be treated as an
implementation detail. It's a full programming language that happens to
compile to C.

Jürg

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

> Vala of course - http://live.gnome.org/Vala
>
> if you like c#/java but want c speed and efficiency then there is no
> better language

Interesting.
i've read it and saw a few examples but am not getting it completely..

If i'm correct (?) than the you write vala coding which is "converted"
to c coding and than compiled? if that's the case that your actually
writing a c program but just with a easier to understand and faster to
learn syntax?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

> for now it cross compiles into c but its a mistake to assume its just
> syntactic sugar!

So that means that (for now) it is "syntatic sugar" and is basically
c. so the compiled program has the memory and speed advantages of c.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ross Burton]

On Sun, 2007-12-02 at 16:07 +, jamie wrote:
> > If i'm correct (?) than the you write vala coding which is "converted"
> > to c coding and than compiled? if that's the case that your actually
> > writing a c program but just with a easier to understand and faster to
> > learn syntax?
> > 
> 
> vala is a full programming language so in the future it may have a gcc
> backend that produces executable code directly. It has a lot of the
> features of c# and java and can also be debugged via gdb
> 
> for now it cross compiles into c but its a mistake to assume its just
> syntactic sugar!

Indeed, remember that back in the days C++ just converted to C.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[jamie]

On Sun, 2007-12-02 at 17:03 +0100, Mark wrote:
> > Vala of course - http://live.gnome.org/Vala
> >
> > if you like c#/java but want c speed and efficiency then there is no
> > better language
> 
> Interesting.
> i've read it and saw a few examples but am not getting it completely..
> 
> If i'm correct (?) than the you write vala coding which is "converted"
> to c coding and than compiled? if that's the case that your actually
> writing a c program but just with a easier to understand and faster to
> learn syntax?
> 

vala is a full programming language so in the future it may have a gcc
backend that produces executable code directly. It has a lot of the
features of c# and java and can also be debugged via gdb

for now it cross compiles into c but its a mistake to assume its just
syntactic sugar!

jamie


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[jamie]

On Sun, 2007-12-02 at 16:30 +0100, Mark wrote:
> With that memory usage i wouldn't mind it at all if ALL my memory was
> used up and my OS was lightning fast.. but that's not the case. it's
> just poor memory usage of those applications.
> 
> And i understand the "programmers" that make python based applications
> (or c#) but that has some issues along the way.
> You spend more memory with those apps and they are bad for your
> performance.. if they would have been written in c or c++ than it
> wouldn't use that much memory and the performance would have been a
> lot better.
> 
> But well.. c/c++ is hard to learn. Python isn't that hard and the same
> applications can be build with it so that's probably why it's tempting
> use it.. but it does blow up the memory usage and kills performance..
> 
> At the moment i'm learning Java.. which can also do all those
> applications but it has the same issues as python (in performance and
> memory). Is there any "easy to learn" language that isn't killing
> performance and isn't taking up extreme amounts of memory? (ruby?)
> this article [1] might be interesting
> 
> [1] http://www.dmh2000.com/cjpr/



Vala of course - http://live.gnome.org/Vala

if you like c#/java but want c speed and efficiency then there is no
better language


jamie


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

With that memory usage i wouldn't mind it at all if ALL my memory was
used up and my OS was lightning fast.. but that's not the case. it's
just poor memory usage of those applications.

And i understand the "programmers" that make python based applications
(or c#) but that has some issues along the way.
You spend more memory with those apps and they are bad for your
performance.. if they would have been written in c or c++ than it
wouldn't use that much memory and the performance would have been a
lot better.

But well.. c/c++ is hard to learn. Python isn't that hard and the same
applications can be build with it so that's probably why it's tempting
use it.. but it does blow up the memory usage and kills performance..

At the moment i'm learning Java.. which can also do all those
applications but it has the same issues as python (in performance and
memory). Is there any "easy to learn" language that isn't killing
performance and isn't taking up extreme amounts of memory? (ruby?)
this article [1] might be interesting

[1] http://www.dmh2000.com/cjpr/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ross Burton]

On Sun, 2007-12-02 at 18:05 +0300, Nickolay V. Shmyrev wrote:
> http://nshmyrev.narod.ru/temp/mixer-applet-massif.tar.gz one can
> download massif results for mixer applet. Large amount of memory spent
> on gst registry xml parsing. Not strange since the registry is around
> 250 kb xml file in my case.

Doesn't gstreamer have an optional binary registry these days?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Nickolay V. Shmyrev]

В Вск, 02/12/2007 в 16:05 +0300, Nickolay V. Shmyrev пишет:
> Heh, sadly memory problems are rather complicated and hidden deeply
> inside the stack thus require very experienced knowledge. From my
> experience the significant amount of memory consumption can be dropped
> by switching to some lightweight gtk theme like Simple.
> 
> I traced mixer applet for example with G_SLICE=always-malloc and some of
> the entries look interesting. For example we spend 150 k on xml parser
> we can avoid. Another 150 k are hanging in options. I'm attaching the
> patch, not sure how correct is it.
> 
> The rest of the log is attached too.

As chpe kindly pointed, of course the patch is not correct,
option-context is construct-only property. But you get the idea, options
are only used during startup, so one can hack libgnome to free context
just after options are parsed.

For those interested, here 

http://nshmyrev.narod.ru/temp/mixer-applet-massif.tar.gz one can
download massif results for mixer applet. Large amount of memory spent
on gst registry xml parsing. Not strange since the registry is around
250 kb xml file in my case.



signature.asc
Description: Эта часть	 сообщения	 подписана	 цифровой	 подписью
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Nickolay V. Shmyrev]

hВ Сбт, 01/12/2007 в 22:11 +, Martin Ebourne пишет:
> On Fri, 30 Nov 2007 09:34:09 +0100, Mark wrote:
> > i was just looking through the system monitor to see how my memory usage
> > was doing and that gave me a impressive (negative way) result. I've made
> > a screenshot [1] of it and edited it a little.
> > ...
> > Now the notebook i'm typing this on has 1GB om memory and runs Fedora
> > fine so if i look at it that way than the ram usage is fine. but keep in
> > mind the people with less memory (256 or 512 MB's) they are gonna get a
> > hard time with this fedora. My total memory usage at the time of this
> > writing is: 432.00 MB (with GIMP on.. if that's closed than it's "just"
> > 400 MB).
> > 
> > What i'm trying to say here is that those gnome-panel applets are taking
> > up way to much memory regardless of the memory you can afford or have in
> > your computer.
> > ...
> > So.. is something gonna change with this memory abuse?
> > , 
> > [1]
> > http://img504.imageshack.us/img504/6821/screenshotsystemmonitoryh4.png
> 
> I agree with you completely about the memory usage of Fedora 8, it has 
> got VERY bloated recently.

Heh, sadly memory problems are rather complicated and hidden deeply
inside the stack thus require very experienced knowledge. From my
experience the significant amount of memory consumption can be dropped
by switching to some lightweight gtk theme like Simple.

I traced mixer applet for example with G_SLICE=always-malloc and some of
the entries look interesting. For example we spend 150 k on xml parser
we can avoid. Another 150 k are hanging in options. I'm attaching the
patch, not sure how correct is it.

The rest of the log is attached too.

Index: panel-applet.h
===
--- panel-applet.h	(revision 10707)
+++ panel-applet.h	(working copy)
@@ -199,6 +199,7 @@
   GNOME_CLIENT_PARAM_SM_CONNECT, FALSE,	\
   GNOME_PROGRAM_STANDARD_PROPERTIES,	\
   NULL);	\
+	g_option_context_free (context);  	\
 retval = panel_applet_factory_main (iid, type, callback, data);		\
 	g_object_unref (program);		\
 	return retval;\
@@ -214,6 +215,8 @@
   argc, argv,\
   GNOME_CLIENT_PARAM_SM_CONNECT, FALSE,	\
   GNOME_PARAM_NONE);			\
+	g_object_set (program, GNOME_PARAM_GOPTION_CONTEXT, NULL);		\
+	g_option_context_free (context);  	\
 retval = panel_applet_factory_main (iid, type, callback, data);		\
 	g_object_unref (program);		\
 	return retval;\
@@ -239,6 +242,8 @@
   GNOME_CLIENT_PARAM_SM_CONNECT, FALSE,	\
   GNOME_PROGRAM_STANDARD_PROPERTIES,	\
   NULL);	\
+	g_object_set (program, GNOME_PARAM_GOPTION_CONTEXT, NULL);		\
+	g_option_context_free (context);  	\
 retval = panel_applet_factory_main (iid, type, callback, data);		\
 	g_object_unref (program);		\
 	return retval;\
@@ -260,6 +265,8 @@
   GNOME_PARAM_GOPTION_CONTEXT, context,	\
   GNOME_CLIENT_PARAM_SM_CONNECT, FALSE,	\
   GNOME_PARAM_NONE);			\
+	g_object_set (program, GNOME_PARAM_GOPTION_CONTEXT, NULL);		\
+	g_option_context_free (context);  	\
 retval = panel_applet_factory_main (iid, type, callback, data);		\
 	g_object_unref (program);		\
 	return retval;\
==6802== 
==6802== 92,305 bytes in 141 blocks are still reachable in loss record 197 of 201
==6802==at 0x40051F9: malloc (vg_replace_malloc.c:149)
==6802==by 0x5B2B2C: (within /usr/lib/libfreetype.so.6.3.8)
==6802==by 0x5B7660: FT_Alloc (in /usr/lib/libfreetype.so.6.3.8)
==6802==by 0x5B7B06: FT_New_Library (in /usr/lib/libfreetype.so.6.3.8)
==6802==by 0x5B2EB6: FT_Init_FreeType (in /usr/lib/libfreetype.so.6.3.8)
==6802==by 0x4DC38B: (within /usr/lib/libpangocairo-1.0.so.0.1600.1)
==6802==by 0x47B989: g_type_create_instance (in /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x463171: (within /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x460D8A: g_object_newv (in /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x46192E: g_object_new_valist (in /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x461ADF: g_object_new (in /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x4D9B6B: pango_cairo_font_map_new (in /usr/lib/libpangocairo-1.0.so.0.1600.1)
==6802== 
==6802== 
==6802== 119,364 bytes in 1,571 blocks are still reachable in loss record 198 of 201
==6802==at 0x40052ED: realloc (vg_replace_malloc.c:306)
==6802==by 0x7718DA: g_realloc (in /lib/libglib-2.0.so.0.1400.0)
==6802==by 0x4739EE: (within /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x473B57: (within /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x47C15C: g_type_register_static (in /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x463B64: g_param_type_register_static (in /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x467B6B: (within /lib/libgobject-2.0.so.0.1400.0)
==6802==by 0x47429E: g_type_init_wit

Re: Extreme memory usage for gnome-panel related apps

[Vincent Untz]

Le samedi 01 décembre 2007, à 03:12 +, Brian Nitz a écrit :
> I'll spare the details of the Anonymous memory used by all libraries in 
> gnome-panel's address space, but notice that restarting gnome-panel 
> reduced the heap from over 15M to about 2M when I restarted 
> gnome-panel.  Occasionally I see halting behaviour in gnome-panel menus 
> which may be caused by paging activity.   Did anything recently change 
> in gnome-panel's memory management?

No, I don't think so.

> When was gslice introduced?

In glib 2.9/2.10. glib 2.10.0 was released in February 2006.

> How can I disable it?   Gslice might not be necessary on Solaris since 
> running with a slab allocator is as simple as setting LD_PRELOAD to 
> libumem.so.

G_SLICE=always-malloc

Keep us informed if you look at this in more details!

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Philip Withnall]

On Sat, 2007-12-01 at 22:11 +, Martin Ebourne wrote:
> On Fri, 30 Nov 2007 09:34:09 +0100, Mark wrote:
> > i was just looking through the system monitor to see how my memory usage
> > was doing and that gave me a impressive (negative way) result. I've made
> > a screenshot [1] of it and edited it a little.
> > ...
> > Now the notebook i'm typing this on has 1GB om memory and runs Fedora
> > fine so if i look at it that way than the ram usage is fine. but keep in
> > mind the people with less memory (256 or 512 MB's) they are gonna get a
> > hard time with this fedora. My total memory usage at the time of this
> > writing is: 432.00 MB (with GIMP on.. if that's closed than it's "just"
> > 400 MB).
> > 
> > What i'm trying to say here is that those gnome-panel applets are taking
> > up way to much memory regardless of the memory you can afford or have in
> > your computer.
> > ...
> > So.. is something gonna change with this memory abuse?
> > , 
> > [1]
> > http://img504.imageshack.us/img504/6821/screenshotsystemmonitoryh4.png
> 
> I agree with you completely about the memory usage of Fedora 8, it has 
> got VERY bloated recently.
> 

*snip*

> To verify the numbers above I killed these tasks off and checked the 
> reduction in used space (- buffers). The expectation is to see the 
> private memory returned, and that's almost exactly what I got:
> 
> 1 x deskbar-applet  35MB
> 2 x beagled 44MB
> 2 x sealert 32MB

deskbar-applet and beagled are both interpreted programs
(deskbar-applet's written in Python, and beagled in C#), so you'll be
taking a performance and memory hit for those.

Philip

> Over 100MB returned by removing a few almost never used programs, but I'm 
> still at 698MB, which is still way too much.
> 
> Looking back up that list there's many other things that are using too 
> much memory. How does a clock applet use over 6MB of private memory?
> 
> Cheers,
> 
> Martin.
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Martin Ebourne]

On Fri, 30 Nov 2007 09:34:09 +0100, Mark wrote:
> i was just looking through the system monitor to see how my memory usage
> was doing and that gave me a impressive (negative way) result. I've made
> a screenshot [1] of it and edited it a little.
> ...
> Now the notebook i'm typing this on has 1GB om memory and runs Fedora
> fine so if i look at it that way than the ram usage is fine. but keep in
> mind the people with less memory (256 or 512 MB's) they are gonna get a
> hard time with this fedora. My total memory usage at the time of this
> writing is: 432.00 MB (with GIMP on.. if that's closed than it's "just"
> 400 MB).
> 
> What i'm trying to say here is that those gnome-panel applets are taking
> up way to much memory regardless of the memory you can afford or have in
> your computer.
> ...
> So.. is something gonna change with this memory abuse?
> , 
> [1]
> http://img504.imageshack.us/img504/6821/screenshotsystemmonitoryh4.png

I agree with you completely about the memory usage of Fedora 8, it has 
got VERY bloated recently.

This laptop is x86_64 and has 1GB RAM. Up to and including FC6 this was 
fine and it hardly ever reached the limit, performance was always good. 
Starting with Fedora 7, and really much more obvious now with Fedora 8 
I'm finding it's using far too much RAM and regularly hitting swap very 
badly. Performance has suffered considerably. I've been thinking of 
shelling out some cash on 2x 1GB SODIMMs, but unfortunately these DDR1 
versions are very expensive.

As an example, there's two users logged in at the moment, I'm running 
evolution, galeon, and an xterm. The other login has nothing extra 
running, it's just gnome.

Here is the output of free:

 total   used   free sharedbuffers cached
Mem:   10276561008372  19284  0  43276 135564
-/+ buffers/cache: 829532 198124
Swap:  1048568 481048520

Yes, 810MB of memory really in use. I'm running gdesklets but not running 
other new stuff such as NetworkManager, yum applets, compiz etc. This 
level of memory use feels quite excessive.

Unfortunately determining where RAM has gone is still somewhat difficult 
on Linux. It would be great to have Matt Mackall's patches in, or Exmap 
available. The best I've found without having to patch the kernel is:
http://www.pixelbeat.org/scripts/ps_mem.py

Running this as root, the biggest culprits are:

 Private  +   Shared  =  RAM used   Program 
  3.4 MiB +   7.6 MiB =  11.0 MiB   notification-area-applet (2)
 10.6 MiB +   1.8 MiB =  12.4 MiB   gconfd-2 (2)
 11.8 MiB +   1.3 MiB =  13.1 MiB   bbackupd
  4.4 MiB +   9.4 MiB =  13.8 MiB   evolution-alarm-notify (2)
  5.3 MiB +   8.9 MiB =  14.2 MiB   mail-notification (2)
  4.7 MiB +   9.7 MiB =  14.4 MiB   metacity (2)
  8.2 MiB +   7.5 MiB =  15.7 MiB   gnome-power-manager (2)
  4.1 MiB +  11.6 MiB =  15.7 MiB   padevchooser
 15.3 MiB + 556.0 KiB =  15.8 MiB   restorecond
 14.5 MiB +   1.6 MiB =  16.1 MiB   xterm
  6.0 MiB +  10.3 MiB =  16.3 MiB   notification-daemon (2)
  6.0 MiB +  11.7 MiB =  17.7 MiB   wnck-applet (2)
  6.1 MiB +  11.7 MiB =  17.8 MiB   clock-applet (2)
  8.8 MiB +  12.5 MiB =  21.3 MiB   mixer_applet2 (2)
 11.0 MiB +  13.4 MiB =  24.5 MiB   gnome-panel (2)
 13.9 MiB +  15.7 MiB =  29.7 MiB   /usr/libexec/re
 23.0 MiB +   9.0 MiB =  31.9 MiB   gnome-settings-daemon (2)
 21.5 MiB +  15.8 MiB =  37.3 MiB   nautilus (2)
 23.9 MiB +  18.0 MiB =  41.9 MiB   evolution
 30.3 MiB +  13.2 MiB =  43.5 MiB   /usr/bin/sealer (2)
 34.7 MiB +  14.7 MiB =  49.5 MiB   deskbar-applet
 43.1 MiB +   8.5 MiB =  51.7 MiB   beagled (2)
 50.8 MiB +  10.4 MiB =  61.2 MiB   Xorg (2)
 80.2 MiB +  12.7 MiB =  92.9 MiB   python (4)
 80.6 MiB +  16.1 MiB =  96.7 MiB   galeon

Galeon seems a bit heavy at 80M for a few tabs, but mozilla based browers 
aren't renowned for being light.

What really stands out for me here is deskbar-applet, how can that be 
using all that memory? Also sealert and beagled are very excessive.

To verify the numbers above I killed these tasks off and checked the 
reduction in used space (- buffers). The expectation is to see the 
private memory returned, and that's almost exactly what I got:

1 x deskbar-applet  35MB
2 x beagled 44MB
2 x sealert 32MB

Over 100MB returned by removing a few almost never used programs, but I'm 
still at 698MB, which is still way too much.

Looking back up that list there's many other things that are using too 
much memory. How does a clock applet use over 6MB of private memory?

Cheers,

Martin.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Elijah Newren]

On Nov 30, 2007 2:46 PM, Mark <[EMAIL PROTECTED]> wrote:
> 2007/11/30, David Zeuthen <[EMAIL PROTECTED]>:
> >  http://live.gnome.org/GnomeLove
> >
> > to learn more about how you can help fix these things in the GNOME
> > Desktop. Thanks.
>
> oh men.. do they really have that.. they must have been in a funny
> mode when they thought about that name. But about the contributing

The name was coined by a non-native English speaker if memory serves
me right.  But yeah, it's a lousy name.


Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen]

On Fri, 2007-11-30 at 22:46 +0100, Mark wrote:
> oh men.. do they really have that.. they must have been in a funny
> mode when they thought about that name. But about the contributing
> part.. providing patches for gnome (if even possible for me) isn't a
> problem.. that's fine but making new frameworks to improve the way
> gnome is running isn't something i would like to have for gnome only..
> things like that should just be available for any window manager
> (gnome, kde, openbox xfce etc..) but than again.. it will take at
> least a few years before i'm even capable of making a framework in C.
> (learning Java now) o well.. that's where the "patience" drops in ^_^

That's fine, learning how to write and contribute code doesn't happen
overnight. My point simply was that the topics you raise are already
well understood by people hacking on the code.. So in a way, and sorry
for sounding harsh, it's pretty disruptive and time consuming to read
such mails. Suppose just 60 developers each spent 10 minutes reading
this thread. That's ten man hours that could have been spent on fixing
bugs or implementing features.

The other point was that there are better forums (GNOME Love is one) to
learn about the problems and how to solve them. As much as I hate
linking to ESR's papers about contributing to open source, here they are

 http://www.catb.org/~esr/faqs/hacker-howto.html
 http://www.catb.org/~esr/faqs/smart-questions.html

Hope this helps.

 David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

2007/11/30, David Zeuthen <[EMAIL PROTECTED]>:
>
> Hi Markg85,
>
> On Fri, 2007-11-30 at 21:52 +0100, Mark wrote:
> > It's all a mather of time, money, patience and programming skills
> > and i can't do it (yet)
>
> I must applaud you for your enthusiasm. However, it's a bit disruptive
> with these kind of mails on developer lists. May I suggest joining the
> GNOME Love project
>
>  http://live.gnome.org/GnomeLove
>
> to learn more about how you can help fix these things in the GNOME
> Desktop. Thanks.
>
>   David

oh men.. do they really have that.. they must have been in a funny
mode when they thought about that name. But about the contributing
part.. providing patches for gnome (if even possible for me) isn't a
problem.. that's fine but making new frameworks to improve the way
gnome is running isn't something i would like to have for gnome only..
things like that should just be available for any window manager
(gnome, kde, openbox xfce etc..) but than again.. it will take at
least a few years before i'm even capable of making a framework in C.
(learning Java now) o well.. that's where the "patience" drops in ^_^

> p.s. : btw, it's considered bad form to cross-post between lists
> you did on your original mail. Please don't do that.

I will try to remember it. i rarely do cross mailing list posting.
this was actually the first or second time.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen]

Hi Markg85,

On Fri, 2007-11-30 at 21:52 +0100, Mark wrote:
> It's all a mather of time, money, patience and programming skills
> and i can't do it (yet)

I must applaud you for your enthusiasm. However, it's a bit disruptive
with these kind of mails on developer lists. May I suggest joining the
GNOME Love project

 http://live.gnome.org/GnomeLove

to learn more about how you can help fix these things in the GNOME
Desktop. Thanks.

  David

p.s. : btw, it's considered bad form to cross-post between lists like
you did on your original mail. Please don't do that.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

2007/11/30, Benjamin Gramlich <[EMAIL PROTECTED]>:
> About three months ago, Vincent proposed changes to the gnome-panel that
> would remove the bonobo usage and switch to d-bus, as well as create a
> new library/compatibility layer to handle applets [1]. It seems that
> this high memory consumption is a reality (I often have close to 500MB
> consumed at any given time, and that's sans compositor). Is it possible
> that when the panel is re-written we could address these concerns and
> make the panel and applets more nimble?
>
> benjamin gramlich

Very interesting.

And about all those libraries.. i don't know exactly how windows is
doing it but isn't windows caching all there libraries? or just the
ones that are used mostly? whichever one it is.. i think fedora (and
linux in general) should cache all libraries that are most used.
(caching all might be a little big). And yes a algorithm has to made
for it and probably even a  upstream kernel patch to do it in the
kernel ?... and just a good caching mechanism that lies in the kernel
and is smart (meaning it will detect what you used and cache the most
used files during boot time) is something that i really miss in Linux
in general.. programs are relatively slow under linux now while they
can be a lot faster with smart caching (no readahead or preload at
least not in there current shape)...  just my thoughts.

Than small sized applets (like the nm-applet and the volume control
shouldn't take more than 500 KB in the memory and still be a lot
faster than they are now.

And about this question:
"Did anyone notice, that Fedora 8 Gnome startup takes roughly two
times longer than Fedora 6 one?"

well.. i did notice that it was taking (a lot) longer than in earlier
Fedora versions and other distributions not Fedora 6 in particular.

It's all a mather of time, money, patience and programming skills
and i can't do it (yet)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Benoît Dejean]

Le vendredi 30 novembre 2007 à 09:36 +, Ross Burton a écrit :

> > And how do i see which files are open?
> 
> ls /proc/[pid]/fd/

Simply right-click.
-- 
Benoît Dejean
GNOME http://www.gnomefr.org/
LibGTop http://directory.fsf.org/libgtop.html


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Benjamin Gramlich]

About three months ago, Vincent proposed changes to the gnome-panel that
would remove the bonobo usage and switch to d-bus, as well as create a
new library/compatibility layer to handle applets [1]. It seems that
this high memory consumption is a reality (I often have close to 500MB
consumed at any given time, and that's sans compositor). Is it possible
that when the panel is re-written we could address these concerns and
make the panel and applets more nimble?

benjamin gramlich


[1] http://live.gnome.org/RoadMap

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Bastien Nocera]

On Fri, 2007-11-30 at 09:34 +0100, Mark wrote:
> // begin note
> 
> i posted this in the fedora-list first but wasn't getting reply's that
> are discussing what i say below. And for the memory (in the text
> below).. Using it all up doesn't mean that it's used good. See it like
> your a rich guy. you can spend it all at once or just go easy on it. i
> would like to go for the latter one. + send to the gnome desktop devel
> list
> 
> // end note
> 
> 
> Hey,
> 
> i was just looking through the system monitor to see how my memory
> usage was doing and that gave me a impressive (negative way) result.
> I've made a screenshot [1] of it and edited it a little. The color
> that i added in mean:
> 
> - darkred : extreme memory usage for..?? nothing?
> - red : gnome-panel related things (applets mostly)
> - orange : first applet UNDER one MB.

> 0.7 MB (bluetooth-applet)


bluetooth-applet isn't an applet, it's a notification area icon, thus
doesn't load the panel applet libraries and dependencies into its
address space. You're most certainly gaining a couple of megs there.

But your tests are flawed, see Ross' mails, they point to explanations
on how to gather memory usage data.

Cheers

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Brian Nitz]

I typically leave gnome-panel (gnome 2.20.1 on Solaris Nevada) running 
for weeks in a Sun Ray session.  The heap does appear to be growing over 
time:

pmap -x of gnome-panel process BEFORE restart of gnome-panel:

22817:  gnome-panel --sm-client-id 11819cdc2800011951517610052150048 
--scr
 Address  Kbytes RSSAnon  Locked Mode   Mapped File
0001 496 488   -   - r-x--  gnome-panel
0009A000  24  24  16   - rwx--  gnome-panel
000A345634561432   - rwx--[ heap ]
0040   12288   12288   12288   - rwx--[ heap ]
F92813121024   -   - r-x--  libcrypto.so.0.9.8
F93D8000 104  96   -   - rwx--  libcrypto.so.0.9.8
F93F2000   8   -   -   - rwx--  libcrypto.so.0.9.8
F94053441640   -   - r  icon-theme.cache
 ...


pmap -x of gnome-panel process AFTER restart of gnome-panel:

3024:gnome-panel --sm-client-id 
11819cdc2800011951517610052150048 --scr
 Address  Kbytes RSSAnon  Locked Mode   Mapped File
0001 496 488   -   - r-x--  gnome-panel
0009A000  24  24  24   - rwx--  gnome-panel
000A196019601960   - rwx--[ heap ]
F94053441640   -   - r  icon-theme.cache
F9C070565904   -   - r  icon-theme.cache
FA35  16  16   -   - r-x--  libmoniker_std_2.so
FA362000   8   8   8   - rwx--  libmoniker_std_2.so
FA37  32  32   -   - r-x--  
libstartup-notification-1.so.0.0.0
FA386000   8   8   8   - rwx--  
libstartup-notification-1.so.0.0.0
FA39   8   8   8   - rwx--[ anon ]
FA3A  88  80   -   - r-x--  libgnome-desktop-2.so.2.3.14
FA3C4000   8   8   8   - rwx--  libgnome-desktop-2.so.2.3.14
FA3D  16  16   -   - r-x--  libpixbufloader-png.so
FA3E2000   8   8   8   - rwx--  libpixbufloader-png.so
FA3F  64  16  16   - rwx--[ anon ]
FA41 384 192   -   - rwxs-[ shmid=null ]
FA4835201496   -   - r  icon-theme.cache
FA81  32  32   -   - r-x--  libesd.so.0.2.38
...

I'll spare the details of the Anonymous memory used by all libraries in 
gnome-panel's address space, but notice that restarting gnome-panel 
reduced the heap from over 15M to about 2M when I restarted 
gnome-panel.  Occasionally I see halting behaviour in gnome-panel menus 
which may be caused by paging activity.   Did anything recently change 
in gnome-panel's memory management?When was gslice introduced?  How 
can I disable it?   Gslice might not be necessary on Solaris since 
running with a slab allocator is as simple as setting LD_PRELOAD to 
libumem.so.



Ross Burton wrote:
> On Fri, 2007-11-30 at 10:51 +0100, Mark wrote:
>   
>>> It's only leaked 2000 bytes, you'll need to do more research on the
>>> 422000 bytes which are still reachable.
>>>   
>> how do i do that? (gonna read the "MemoryReduction" docs soon)
>> 
>
> Read the valgrind help page.
>
> Ross
>   
> 
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>   

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ross Burton]

On Fri, 2007-11-30 at 10:51 +0100, Mark wrote:
> > It's only leaked 2000 bytes, you'll need to do more research on the
> > 422000 bytes which are still reachable.
> 
> how do i do that? (gonna read the "MemoryReduction" docs soon)

Read the valgrind help page.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

2007/11/30, Ross Burton <[EMAIL PROTECTED]>:
> On Fri, 2007-11-30 at 10:29 +0100, Mark wrote:
> > Oke the first valgrind results of nm-applet. it has leaks.
> >
> > ==5832== ERROR SUMMARY: 10 errors from 2 contexts (suppressed: 123 from 2)
> > ==5832== malloc/free: in use at exit: 517,672 bytes in 7,809 blocks.
> > ==5832== malloc/free: 27,957 allocs, 20,148 frees, 7,621,756 bytes 
> > allocated.
> > ==5832== For counts of detected errors, rerun with: -v
> > ==5832== searching for pointers to 7,809 not-freed blocks.
> > ==5832== checked 1,407,576 bytes.
> > ==5832==
> > ==5832== LEAK SUMMARY:
> > ==5832==definitely lost: 2,770 bytes in 56 blocks.
> > ==5832==  possibly lost: 92,192 bytes in 125 blocks.
> > ==5832==still reachable: 422,710 bytes in 7,628 blocks.
> > ==5832== suppressed: 0 bytes in 0 blocks.
>
> It's only leaked 2000 bytes, you'll need to do more research on the
> 422000 bytes which are still reachable.

how do i do that? (gonna read the "MemoryReduction" docs soon)

>
> > But how do i do the "massif skin" and at mmaped files..
>
> $ valgrind --tool=massif
>
> > what is in the
> > actual memory usage? you have:
> > VM Size
> > Private Clean
> > Private Dirty
> > Shared Clean
> > Shared Dirty
>
> "Actual" memory usage doesn't exist.  The "Memory" column tries to
> represent the cost, by counting private memory and its share of the
> shared memory.
>
> > And how do i see which files are open?
>
> ls /proc/[pid]/fd/
>
> http://live.gnome.org/MemoryReduction is full of useful information,
> tips, and identified problems.
>
> Ross

Nice docs!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ross Burton]

On Fri, 2007-11-30 at 10:29 +0100, Mark wrote:
> Oke the first valgrind results of nm-applet. it has leaks.
> 
> ==5832== ERROR SUMMARY: 10 errors from 2 contexts (suppressed: 123 from 2)
> ==5832== malloc/free: in use at exit: 517,672 bytes in 7,809 blocks.
> ==5832== malloc/free: 27,957 allocs, 20,148 frees, 7,621,756 bytes allocated.
> ==5832== For counts of detected errors, rerun with: -v
> ==5832== searching for pointers to 7,809 not-freed blocks.
> ==5832== checked 1,407,576 bytes.
> ==5832==
> ==5832== LEAK SUMMARY:
> ==5832==definitely lost: 2,770 bytes in 56 blocks.
> ==5832==  possibly lost: 92,192 bytes in 125 blocks.
> ==5832==still reachable: 422,710 bytes in 7,628 blocks.
> ==5832== suppressed: 0 bytes in 0 blocks.

It's only leaked 2000 bytes, you'll need to do more research on the
422000 bytes which are still reachable.

> But how do i do the "massif skin" and at mmaped files..

$ valgrind --tool=massif

> what is in the
> actual memory usage? you have:
> VM Size
> Private Clean
> Private Dirty
> Shared Clean
> Shared Dirty

"Actual" memory usage doesn't exist.  The "Memory" column tries to
represent the cost, by counting private memory and its share of the
shared memory.

> And how do i see which files are open?

ls /proc/[pid]/fd/

http://live.gnome.org/MemoryReduction is full of useful information,
tips, and identified problems.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Mark]

2007/11/30, Ross Burton <[EMAIL PROTECTED]>:
> Mark,
>
> Please reply-to-all, you forgot to include the lists.

Oke

> Similar usage, some higher some lower.

Hmm.. sad

Oke the first valgrind results of nm-applet. it has leaks.

==5832== ERROR SUMMARY: 10 errors from 2 contexts (suppressed: 123 from 2)
==5832== malloc/free: in use at exit: 517,672 bytes in 7,809 blocks.
==5832== malloc/free: 27,957 allocs, 20,148 frees, 7,621,756 bytes allocated.
==5832== For counts of detected errors, rerun with: -v
==5832== searching for pointers to 7,809 not-freed blocks.
==5832== checked 1,407,576 bytes.
==5832==
==5832== LEAK SUMMARY:
==5832==definitely lost: 2,770 bytes in 56 blocks.
==5832==  possibly lost: 92,192 bytes in 125 blocks.
==5832==still reachable: 422,710 bytes in 7,628 blocks.
==5832== suppressed: 0 bytes in 0 blocks.


But how do i do the "massif skin" and at mmaped files.. what is in the
actual memory usage? you have:
VM Size
Private Clean
Private Dirty
Shared Clean
Shared Dirty

And how do i see which files are open?

Thanx.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ross Burton]

Mark,

Please reply-to-all, you forgot to include the lists.

On Fri, 2007-11-30 at 10:02 +0100, Mark wrote:
> 2007/11/30, Ross Burton <[EMAIL PROTECTED]>:
> > On Fri, 2007-11-30 at 09:34 +0100, Mark wrote:
> > > Now there are still 3 more left in the list i highlighted.
> > > 1. Nautilus
> > > Oke.. this one is bothering me. at the time that i shot the screenshot
> > > nautilus was not open (at least not the file browser) and than it's
> > > taking up that much memory! that's just overkill!
> >
> > The desktop is managed by nautilus.
> >
> > > 2. gnome-settings-daemon
> > > Why does this need to run? what's the purpose of it? If it's just
> > > running for other programs to grab gnome settings (wild guess) than
> > > it's using up way to much RAM anyway. otherwise it has to go.
> >
> > It's an essential part of the GNOME settings.
> >
> > > So.. is something gonna change with this memory abuse?
> >
> > I suggest that you start by running the applications in valgrind, both
> > the memcheck skin (to find any leaks) and the massif skin (to see where
> > the memory is being used).  You might find some easy to fix low-hanging
> > fruit like large unused images which are not being feed, or mmap'd files
> > which should be closed.
> >
> > Ross
> 
> Do you have about the same memory usage for those applets?
> Or could you post a list of the usage that you have for those applets?

Similar usage, some higher some lower.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Extreme memory usage for gnome-panel related apps

[Ross Burton]

On Fri, 2007-11-30 at 09:34 +0100, Mark wrote:
> Now there are still 3 more left in the list i highlighted.
> 1. Nautilus
> Oke.. this one is bothering me. at the time that i shot the screenshot
> nautilus was not open (at least not the file browser) and than it's
> taking up that much memory! that's just overkill!

The desktop is managed by nautilus.

> 2. gnome-settings-daemon
> Why does this need to run? what's the purpose of it? If it's just
> running for other programs to grab gnome settings (wild guess) than
> it's using up way to much RAM anyway. otherwise it has to go.

It's an essential part of the GNOME settings.

> So.. is something gonna change with this memory abuse?

I suggest that you start by running the applications in valgrind, both
the memcheck skin (to find any leaks) and the massif skin (to see where
the memory is being used).  You might find some easy to fix low-hanging
fruit like large unused images which are not being feed, or mmap'd files
which should be closed.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Extreme memory usage for gnome-panel related apps

[Mark]

// begin note

i posted this in the fedora-list first but wasn't getting reply's that
are discussing what i say below. And for the memory (in the text
below).. Using it all up doesn't mean that it's used good. See it like
your a rich guy. you can spend it all at once or just go easy on it. i
would like to go for the latter one. + send to the gnome desktop devel
list

// end note


Hey,

i was just looking through the system monitor to see how my memory
usage was doing and that gave me a impressive (negative way) result.
I've made a screenshot [1] of it and edited it a little. The color
that i added in mean:

- darkred : extreme memory usage for..?? nothing?
- red : gnome-panel related things (applets mostly)
- orange : first applet UNDER one MB.

Now if you take a look at the image you see that my current gnome
session is taking up:
4.9 MB (gnome-panel)
3.5 MB (mixer_applet2)
3.0 MB (wnck-applet)
2.3 MB (nm-applet)
1.2 MB (notification-area-applet)
1.1 MB (gnome-volume-manager)
0.7 MB (bluetooth-applet)

Totals to: 17.7 MB
That is only the gnome-panel stuff with it's applets. if you are gonna
take into account the stuff that is needed to run the applets (like
python) than it will likely use a lot more but since those a can be
used with other applications as well i will leave that out of it.

Now there are still 3 more left in the list i highlighted.
1. Nautilus
Oke.. this one is bothering me. at the time that i shot the screenshot
nautilus was not open (at least not the file browser) and than it's
taking up that much memory! that's just overkill!

2. gnome-settings-daemon
Why does this need to run? what's the purpose of it? If it's just
running for other programs to grab gnome settings (wild guess) than
it's using up way to much RAM anyway. otherwise it has to go.

3. puplet
Someone said this was efficient in Fedora 8.. doesn't look like it. (8 MB).

Now the notebook i'm typing this on has 1GB om memory and runs Fedora
fine so if i look at it that way than the ram usage is fine. but keep
in mind the people with less memory (256 or 512 MB's) they are gonna
get a hard time with this fedora. My total memory usage at the time of
this writing is: 432.00 MB (with GIMP on.. if that's closed than it's
"just" 400 MB).

What i'm trying to say here is that those gnome-panel applets are
taking up way to much memory regardless of the memory you can afford
or have in your computer. It should just be as fast and small as
possible with all the needed functions. 3.5 MB for the mixer applet
(which doesn't even support pulseaudio streams and is really basic!)
is just overkill (btw it's taking up 4.6 MB now). Perhaps all those
applets need to be checked on memory usage? or a completely new
gnome-panel + applets that just take up a few MB in total (instead of
17.7). Gnome and Fedora are currently looking fine the way they are.
so perhaps it's time to stop spending time on features for a while (2
releases? till Fedora 10?) and start spending all time/money/efforts
on performance  memory usage and usability.

And again for the memory. Having much doesn't need that it needs to
use much! slow pc's with less memory should be able to run fedora
right? Simple example. imagine that a slow 500 MHz pc with 512MB
memory wants to run Fedora + compizfusion + Gimp. Now at this moment
he must drop compiz or gimp. if that panel stuff was just using normal
amounts of memory he would have been able to use all 3 (just a
example!!)

So.. is something gonna change with this memory abuse?

[1] http://img504.imageshack.us/img504/6821/screenshotsystemmonitoryh4.png
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list