Re: Time to heat up the new module discussion

[Darren Kenny <Darren Kenny Sun COM>]

Ben Maurer wrote:
> 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.

Not yet - but this is where I think we need the separation between Core GNOME.

> 
>> 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).

Not in all cases - and one daemon running on a machine is very different to lots
of libs loaded - and the non-shared memory that comes with this. In fact I'd be
all for the use of more daemons if it saved all apps having to load lots of
libraries - the loading would be limited to one place!

Again I think people seriously need to get out of the mind-set that there is
only one desktop user on a machine - so a couple of meg for 1 user isn't a lot -
but for 100 users on a single machine (even with 256Mb of RAM per user) there is
a huge impact in that "tiny" additional platform being loaded. This is a major
issue for us in Sun since we have to effectively disable the use of such things
and also the use of busy "idle" apps (i.e. ones that poll every second or so)
since the CPU share that is available to each user here is tiny... This is why
we need a Core GNOME that isn't dependent on such frameworks.

While I understand that Sun Ray is a special case, it's a valid case - even
thinking of several VNC sessions on a single machine or some of those new
machines with multiple keyboard/mouse and display combinations directly attached...

> 
>> Just think about what happens when a user logs into a desktop that has Py thon
>> 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.

OK, they are - but each one of the had to map that much into memory before it
could be figured out which parts could be shared - so there is still a cost in
running them, and maintaining them. Also there is still quite a bit not
shareable - as much as 8/10 MB - so for 10 applets (which is quite possible)
that's 100Mb - and this is for the C based applets [I still think there must be
a way to resolve this, but that's another story] - then for each python applet
or Mono applet, you can add a considerable larger set of initial libraries (this
contributes significantly to start-up/login time, but I admit mainly for the
first-time run) and then more RSS for the "platforms" own processing space. Also
then most of these have garbage collection routines - so they have the need to
do that when supposedly idle, and so end up using more CPU - again i draw your
attention to the multi-seat machine.

> 
>>  - 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.
> 

Yes, and I still don't think it should be in Core GNOME, as I said I'd like to
see these other "platforms" as being outside of the Core GNOME.

> 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.

Yes, innovation comes in the form of prototypes - that doesn't mean the final
solution should also use these - e.g. in MS Windows how many final applications
use VB, most used VB for the prototyping, but then switched to C++/MFC for the
final versions.

This is where I think the main strength of C# or Python lie.

> 
> 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.

Again - this garbage collection is fine on a single-user machine - in the
multi-user case GC is very expensive.

> 
>> 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.

Glad to hear it ;)

> 
>> 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.

The key word is "Most" - it's still an issue if we start migrating to nearly all
our new development being done in C# or Python (or anything else like that,
including Java) - once we do, we start alienating the ones that don't (and
Solaris doesn't).

If you look at all the new applications being developed in GNOME - how many are
done using C?? VERY few - this is very worrying for the future of GNOME.

> 
>> 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.

It does from the perspective of "choice" - if someone decides they don't want to
use platforms like Mono or Python due to it performance hit, then it should be
possible to make that choice - by making something like this Core - the choice
isn't there any more.

> 
> 
> 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:

Fair enough, the bloated-ness of the whole things is only part of the problem
(it's very important for us in Sun and the use of Sun Ray). We need to be able
to decided what we do and don't want to include - e.g. we would like user to be
able to decided to not install Python or Mono yet still have a very usable
desktop - this is where I think we need to be very strict about what is
considered Core - e.g. would you write a window manager or panel in Python and
expect people to use this as the final version - no, you would test things using
this and then look at solidifying it using the native interfaces.

> 
> 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.

OK, but what defines "not started by default" - I think this is where we need
the definition of Core... If it's in the Core you would expect people to
possibly have it started by default (ie. saved in their session).

> 
> 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.

OK, but I would have to see new libraries being written in C# and a C binding
being given for it that other Core items suddenly start using!

> 
> 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.
> 

I'm all for innovation - as long as it doesn't exclude people from using the
Core desktop - including Mono or Python, and misusing it for everyday apps (like
Beagle) could have a negative effect in the long term since these would no
longer be optional compilation elements since they are part of the Core.

Darren.

> -- Ben
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list