Just as you would tune your car, our skilled engineers have striven to tune many parts of GNOME to be as fast as possible. Several important components of the GNOME desktop are now measurably faster, including text rendering, memory allocation, and numerous individual applications. Faster font rendering and memory allocation benefit all GNOME and GTK+ based applications without the need for recompilation. http://www.gnome.org/start/2.20/notes/en/figures/figure-gnom(...)
Some applications have received special attention to make sure they are performing at their peak. GNOME Terminal, the terminal emulator for the GNOME desktop, has been optimized in several ways to make it faster and, at the same time, more resource efficient. The GNOME Log Viewer now starts up over 20 times faster than before.
[...]
As of GLib 2.10, the GSlice allocator replaces the older GMemChunk and GTrashStacks APIs available in GLib. GSlice is very similar to the kernel slab allocator and allows for fast, memory-efficient allocation of small structures (e.g. GList elements, GtkWindow structures). GSlice also has none of the locking overhead of GMemChunk, which makes it much faster in multithreaded applications. http://www.gnome.org/start/2.20/notes/en/figures/figure-gsli(...)
GMemChunk has been reimplemented to transparently use GSlice, but the GMemChunk API is considered deprecated.
To allocate memory with the GSlice allocator, use the call g_slice_new (MyStructure);, which will return a pointer (ptr). To free memory allocated with GSlice, use the function g_slice_free (MyStructure, ptr);.
GSlice uses a scalable, thread-local cache of slices of different sizes. For large memory requirements, GSlice will transparently and automatically use the g_malloc allocator for you, so developers do not have to choose the most efficient allocator themselves.
Wow. Juste wow. Et après y'en a qui vont nous dire que Gnome ne fera pas le moindre progrès si on sort pas un 3.0.
[^] # Re: Pour les plus presses
Posté par satan . En réponse à la dépêche GNOME fête ses dix ans de logiciel libre. Évalué à 3.
http://www.gnome.org/start/2.20/notes/en/figures/figure-gnom(...)
Some applications have received special attention to make sure they are performing at their peak. GNOME Terminal, the terminal emulator for the GNOME desktop, has been optimized in several ways to make it faster and, at the same time, more resource efficient. The GNOME Log Viewer now starts up over 20 times faster than before.
[...]
As of GLib 2.10, the GSlice allocator replaces the older GMemChunk and GTrashStacks APIs available in GLib. GSlice is very similar to the kernel slab allocator and allows for fast, memory-efficient allocation of small structures (e.g. GList elements, GtkWindow structures). GSlice also has none of the locking overhead of GMemChunk, which makes it much faster in multithreaded applications.
http://www.gnome.org/start/2.20/notes/en/figures/figure-gsli(...)
GMemChunk has been reimplemented to transparently use GSlice, but the GMemChunk API is considered deprecated.
To allocate memory with the GSlice allocator, use the call g_slice_new (MyStructure);, which will return a pointer (ptr). To free memory allocated with GSlice, use the function g_slice_free (MyStructure, ptr);.
GSlice uses a scalable, thread-local cache of slices of different sizes. For large memory requirements, GSlice will transparently and automatically use the g_malloc allocator for you, so developers do not have to choose the most efficient allocator themselves.
Wow. Juste wow. Et après y'en a qui vont nous dire que Gnome ne fera pas le moindre progrès si on sort pas un 3.0.