Re: Time to heat up the new module discussion

[Ben Maurer <bmaurer andrew cmu edu>]

Hey,

On Wed, 12 Jul 2006, Darren Kenny wrote:
> It's been mentioned many times before that we already have too many component
> models in the GNOME platform - and once they are in there, it's VERY hard to get
> them back out again - just look at Bonobo.

Bonobo is, by design, intended to be used in many applications. I don't 
think this applies as much to Mono.

> It makes sense to me that Mono should remain on the out-skirts of GNOME for this
> very reason - core GNOME should only use native languages, and more specifically
> C, as to to do otherwise is likely to effect the already perceived poor
> performance of GNOME.

Excess memory usage has not stoped us from using alot of things -- VFS, 
Bonobo, etc. Many of the other modules under consideration add their own 
memory usage to the base desktop -- for example, accepting power manager 
gives us yet another daemon which takes up a few megs of ram. Distros are 
being even more aggressive about adopting these new programs (network 
manager, notification daemon).

> Just think about what happens when a user logs into a desktop that has Python
> and C# based applets included with C based applets:
> - The panel starts
>  - It starts C/Bonobo based applets - the smallest of which already consumes
>    approx 40Mb of memory.
>  - It starts Python applets - each of these takes up approx 70Mb of memory -
>    and very little of this is shared

These numbers are clearly vmsize, which don't make much sense.

>  - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't
>    that small, but I guess at least it does share memory better than Python,
>    but there is still quite a lot of additional memory pulled in.

Mono does *quite* a bit better than python in terms of memory for a Gtk# 
application (vs pygtk).

Look at: http://bugzilla.gnome.org/show_bug.cgi?id=346211. Deskbar applet 
takes 13 MB of ram at startup. This has not stopped us from accepting it.

Innovation comes slowly. Performance tuning is often one of the last steps 
of polish. I think it's clear that much innovation is coming from 
applications written in managed languages. Bringing in Mono will allow 
greater innovation in the GNOME platform.

In the long term, Mono can potentially reduce our performance problems. It 
is often easier to make performance changes in a managed language due to 
the cleaner code that generally comes with the higher level language. 
Also, innovations at the virtual machine level can give us benefits for 
all applications. For example, when Mono has a moving GC, applications 
will be able to return memory to the system *better* than similar apps 
written in C.

> I know today people say that memory is cheap, but I think that's not an excuse
> for working on reducing it's consumption. Also, there is the small devices like
> the Nokia 770 for which memory consumption is a big factor.

I assure you, I'm not one to argue that memory is cheap.

> As for .NET, even Microsoft themselves had to pull back from using it for core
> functionality due to performance reasons - why do we think we will do any better?

Attributing this to performance alone is over simplifying. Vista clearly 
has some high performance requirements. IMHO, part of the issue was that 
rewriting existing code wasn't the way to get Vista out the door. We 
aren't doing that, and I don't think we should.

> I think, and this is only my opinion, we should consider the possibility of
> different levels (for want of a better word) for delivery of GNOME (if it's not
> already been done) - this would be similar to the way GStreamer has split it's
> modules - it makes sense from an ISV or OEM standpoint:
>
> - GNOME Core
> - GNOME Native
> - GNOME Python
> - GNOME Mono

What good does this do us? There are 20 ways we can segment the GNOME 
applications. We can go by applications with bonobo vs those without, 
those that are hogs vs those that aren't. Most distros ship all of it.

> I'm sure there are more breakdowns possible - I just think an ISV or 3rd party
> developer should be able to express their dependencies for their application by
> saying they need GNOME Core or GNOME Mono.

I'm not really aware of the issues and problems in this area. However, 
this doesn't seem to relate to the ideas about performance earlier in the 
email.


IMHO, we should define a process that does not start "Python is bloated, 
C# is bloated. Lets not use them". We must establish clear guidelines as 
to what is allowed. When talking about performance, talk in megabytes, not 
languages. For example:

When suggesting a new feature or module for GNOME that is active at 
startup, the following should be considered:
	- Does this program start any new daemons? How much memory do they
	  use?
	- What efforts have been taken to reduce leaks? How does the
	  application do in a long session?

I also think our guidelines should be less strict on applications not 
launched by default. If Tomboy is added as a non-default application, we 
needn't be as strict about memory usage.

I also think we should set out guidelines for applications in languages 
other than C. For example, they should provide apis so that non-managed 
applications can interact with them.

In the end, we should encourage innovation. GNOME would never be where it 
is today without some of the more bloated releases of years past. When 
their applications are ready for primetime, GNOME must take them with open 
arms.

-- Ben