Re: Time to heat up the new module discussion

[Jamie McCracken <jamiemcc blueyonder co uk>]

Ben Maurer wrote:
> On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr�cinaux wrote:
> > Ben Maurer wrote:
> >
> > > Please read my previous emails. Designing everything in C will not help.
> > > Evolution, OpenOffice and Firefox are evidence that writing your app in
> > > C does not make it memory efficient. In the long term, a moving GC may
> > > be beneficial.
> >
> > Does "using a GC" really mean you have to use a big bloated
> > memory-hungry virtual machine ?
>
> Here we go with the "X is bloated" track again. I'm sure that gtk+ is 
> very bloated because evolution is memory hungry.

evolution is a badly designed app which suffers terribly from 
featuritis. I dont mean any disrespect nor do I portion any blame 
towards its developers cause evolution predates gnome 2's simplification 
phase and was designed to compete with MS outlook.

Evo should be split into several seperate apps - one for mail reading 
others for organiser style apps. Its overkill if all you want is a tool 
to read your mails.

(I dont use evolution as a result)

> > Well, no. Inkscape uses a GC, and it is
> > written in C++.
>
> It's fairly hard to do this. A moving gc in C++ would be even harder.
>
> > If ever VM were able to share libs, it would be a great improvement, but
> > currently they can't. It means the managed part of the code is loaded
>
> Mono can do this. Read about AOT>

AOT is not widely used because it does not offer the same performance of JIT

> > for every managed app you launch. Which is far from optimal in the case
> > of permanently running apps.
>
> Even when we are not AOTing, the amount of ram dedicated to JITed code 
> is small. If you are going to bitch, bitch with NUMBERS. The only 
> performance data on this thread was the vmsize of a few applets, which 
> means absolutely nothing.

Jits on the desktop are usually bad not just because they do take more 
memory but also because you need the build system of mono installed 
which means more bloat.

> Just as a number for starters: when launching banshee without AOT, it 
> takes 600 kb of JITd code space. Let's say it's really more like 1 MB 
> after lots of use (probably higher than it actually is). Maybe there are 
> 4 managed apps (Banshee, F-Spot, Beagle, Tomboy). That's 4 MB vs 1 MB if 
> 100% of it was shared as in C. Not a lot. In the long term, we'll 
> probably get more of a win with compacting from a GC than this.

Every compacting GC automatically doubles memory use - you have two 
managed heaps ergo twice the RAM required. If you copy MS and go for a 
three generation one then you risk trebling memory use over using a 
non-compacting one.

(malloc and free do not return memory to the OS on linux and most other 
systems - the memory is retained for reuse for the app).

Mmap'ping blocks of memory can be returned to the OS but they are at 
least 5x slower than malloc/free and are only worth using with memory pools.

In the end you have to choose between fast garbage collection (and up to 
6x memory use) or slow garbage collection with more modest RAM 
requirements - there is no perfectly efficient *and* fast GC out there 
and they have been searching for it for the last 50 years.

--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/