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 _______________________________________________ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev