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/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
