[Thunar-dev] Gnome is trying to decrease memory usage.

[Benedikt Meurer]

Anders Aagaard wrote:
> Hi
> 
> I noticed http://live.gnome.org/MemoryReduction, and I remember you
> talking about gnome (nautilus in particular)'s ridiculous memory usage. 
> I'm sure they would apriciate some constructive criticism ;), It seems
> they are also working on gtk, which would help xfce/thunar aswell :)

This is pretty old news. GLib already contains some optimizations (like
G_PARAM_STATIC_NAME, etc.). There are a lot of places throughout GTK/GDK
where you could actually save memory (also cairo comes to mind now), but
it's really not that trivial: Most of this (so called) "memory overhead"
is used to provide better performance. You could probably save a few
100k data memory for GTK/GDK in a typical application, but that's not
where most of the memory is wasted. You're better off checking the upper
layers, above GTK, first (and in the special case of glibc/linux, you
should also check the libc layer, as Thunar consumes atleast twice as
much data memory on Linux, dunno why).

Speaking of Nautilus, it's nothing special. You can apply the same
optimizations as everywhere else. For example, reduce the heap (mis)use
for temporary memory (grep'ing for g_strdup_printf() and friends will
usually give a long list of functions, where it would be better to work
on the stack, rather than the heap), reducing the number of wasted bytes
per memory allocation (for example, it would be a good idea to use a
memory chunk for classes like NautilusFile, which are instantiated very
often) and reducing the memory required for "static" library data (e.g.
Gnome-VFS comes to mind here). Gnome-VFS in particular can be seen as a
problem for long-running processes like Nautilus, a concept similar to
KIO would provide better results here. Another important point would be
to reduce the number of shared libraries that are only required by
Nautilus (for example, libeel and libnautilus-private could be linked
statically, or clean them up and merge the required parts into the other
libraries and nautilus itself).

But all these ideas are well known-facts, and by no means new to the
GNOME developers. The problem here is not a technical problem, but more
a political problem. Most of the overhead noticed with GNOME today is
caused by politics (e.g. what goes into which library, why can't we do
this like that, my d*ck is larger than yours, and the like). If people
would sit down for 6 months and do the required code auditing and then
release a clean and stable 2.14, that'd really take them forward (and
don't say that's impossible; for example the OpenBSD guys succeed
because of this concept). But this won't happen in the GNOME community
for various (mostly non-technical) reasons: First of all, nobody wants
to present a new major release that brings nothing new, because
everybody believes that it's necessary to satisfy the user base with
user visible changes. Next, the developer community is split into
various parts, where the two most important parts are the professional
software developers and architects and the spare-time hackers and
programmers. The former would definitly be well suited for the "great
clean up", but the latter would most probably be frustrated by the lack
of "new stuff to hack on" or wouldn't join at all. Another reason is the
fact that there are big companies like Novell and RedHat, that sponsor
quite a few of the important guys in the GNOME community, and if you
ever worked in software business, than you'll know that companies don't
have much interest to pay for "clean up work" usually (no matter if it's
a good thing or not). Again, nothing new.

If you want to know my personal opinion: On the toolkit level, GTK is
still far from where QT is today. It's a pleasure to work with QT in the
professional area (and the Trolltech support is very good) and I'm sure
it's also nice to work with it as part of KDE, while GTK is superior to
QT in certain X-specifc areas (like multi-display support), but it's
less funny to work with (e.g. I'm spending more time checking the actual
implementation than the API documentation, while in case of QT, it's
really seldomly necessary to look at the source). The weird thing is,
that because of this, I know a lot more about GLib/GTK now than I'll
ever know about QT. And, to explain the relation to the topic, the fact
that QT consumes (slightly) more memory than GTK is totally irrelevant,
so maybe the "memory overhead" itself isn't really the problem and the
"memory overhead" argument just shadows the real problem?

> Anders Aagaard

Benedikt