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

[Benedikt Meurer]

Benedikt Meurer wrote:
> 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.

I should make clear, that this is - of course - my POV. Others may (and
will) have a different view on these issues.

And to forestall the next question: Yes, I know about Project Ridley.
This is indeed a chance for GTK, but it's not garantied that GTK will
benefit from it. There's also a good chance that GTK will become the
"GNOME Tool Kit", which will render it useless for many projects (most
probably including Xfce and Thunar).

Benedikt