Re: g_malloc overhead
2009/1/21 Liam R E Quin l...@holoweb.net: On Mon, 2009-01-19 at 18:43 +0100, BJörn Lindqvist wrote: Actually, a custom allocator could be useful even in the general case. Malloc is a system call and has quite bad performance on certain platforms (windows in particular i think). Something like the gslice allocator could Probably improve performance a bit. malloc is a library call. On Linux, it is implemented using mmap() and brk() which are system calls. The point is that malloc usually translates into one or more system calls which are expensive. With a custom allocator the system call part of malloc can be avoided. It's not worth changing memory allocators unless you have a good solid understanding of how your program uses memory, and have done *very* detailed timings. You are right of course. For GSlice in particular, it was tested thoroughly when it was merged to glib. See http://markmail.org/message/ohmuxdfyttuy4ipa. For gtk programs I believe we have quite good understanding on how applications use memory. Another example is Python which also uses a custom memory allocator. It works very well because Python uses lots of short-lived small objects. -- mvh Björn ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: examples/list.c
Hi Deron, Please don't reply to me directly. The entire list should be able to benefit from this discussion. Deron Kazmaier wrote: I'm sure he know that, but is it available or not? I would think it should still be functional otherwise it would not be binary compatible with existing applications. It's available, but you may have problems with it. There have *always* been problems with it IIRC (one of the several reasons its been deprecated since 2.0 [or maybe 2.2]), and it's unsupported and unmaintained. So basically, by using GtkTree or GtkList you are saying, I'm assuming it will work perfectly, because no one will help me with using it, and no one will fix bugs that I find in it. I can almost guarantee you that approach will be problematic. I have my own set of problems with GtkTreeView that prevent me from using it. I suppose the correct thing for me to do would be to simple write my own GtkList. Would probably be easier that fighting GtkTreeView... Why not describe your problems with GtkTreeView instead of just dismissing it out of hand? Perhaps they're just the result of a misunderstanding about how it works. I'll agree that there's a bit of a learning curve to using GtkTreeView, but after you figure out how it works, it's very powerful and flexible and can handle doing just about anything you can think to throw at it. And really, it's not that hard to use. If you intend to do any amount of gtk programming in the future, you'll need to learn it (as the concepts behind GtkTreeView are used in other parts of gtk; see any widget that makes use of GtkTreeModel or GtkCellLayout). Even if this is just a one-off app and you never intend to touch gtk again, you'd likely be saving yourself some time and frustration by learning how to use GtkTreeView properly. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Martín Vales mar...@opengeomap.org writes:
hi:
I working with visual c++ in Windows and i find glib very useful for
many C task, but i am worry about the g_malloc overhead.
We really need a new malloc??
gpointer
g_malloc (gsize n_bytes)
{
if (G_UNLIKELY (!g_mem_initialized))
g_mem_init_nomessage();
if (G_LIKELY (n_bytes))
{
gpointer mem;
mem = glib_mem_vtable.malloc (n_bytes);
if (mem)
return mem;
g_error (%s: failed to allocate %G_GSIZE_FORMAT bytes,
G_STRLOC, n_bytes);
}
return NULL;
}
What are the advantages of use a glib_mem_vtable ???. I think we have
the same malloc function in all operating systems?.
static GMemVTable glib_mem_vtable = {
standard_malloc,
standard_realloc,
standard_free,
standard_calloc,
standard_try_malloc,
standard_try_realloc,
};
g_malloc will abort program when no additional memory is avaible (as
usually programers do not care about handling it as it would require
usually... allocating memory).
From g_try_malloc:
Attempts to allocate n_bytes, and returns NULL on failure. Contrast
with g_malloc(), which aborts the program on failure.
Other overhead i see is the open dir/file funtions, where in windows
we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt
use utf16 by default why in gnome world we use utf8 by default?.
I guess that:
1. Because utf-8 is currently the main coding for unicode I guess (see
xml co.)
2. Because the most strings in latin alphabet will be nearly 2x smaller
then in utf-16 (on average in my mother language AFAIR utf-8 is bigger
by a few % then iso-8859-2 - utf-16 would by 100% bigger)
3. I guess that utf-8 is a standard on main Gnome platform -
GNU/Linux. While I met in many places generating xx_XX.UTF-8 locales
I've never encountered utf-16.
4. utf-16 is not fixed size so this is not an advantage over utf-8
(utf-32 is).
Regards
--
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
