Re: glib: gmain, perf, etc...

[Tim Janik <timj gtk org>]

On Tue, 30 Oct 2001, Grant Taylor wrote:

> >>>>> Tim Janik <timj gtk org> writes:

> > eventhough owen and me cooked up the newly added GQueue
> 
> I'm a little unclear why the GQueue is separate from the GList.  By
> definition, you can push and pop any which way from a doubly linked
> list.  Why aren't there just some "queue" functions on the lists?

cause we don't cache(know) the tail of a list, getting at it is an
O(n) operation.

> >>  - The g_log subsystem is frightfully slow, even for things that are
> 
> > g_log is still on my list of things to change the internals of. the
> > current code is about 3 times more complex than it has to be, just
> > because the memory subsystem wants to report pathologic situations
> > through it as well ;(
> 
> God, that's hopeless.  You'd have to have preallocated everything all
> the way up through the user, and guarantee not to push the stack over
> a new page boundary, as well.  You can check the stack without too
> much trouble, but you'll never be able to say what goes on in an Xlib,
> or GDI, for that matter.
> 
> Speaking of memory, g_malloc is a pain.  It breaks the caller
> information part of the malloc hooks in glibc, so glib users must use
> a stack-tracing tool like debauch or purify to leak-check their
> software.  Does gmalloc really add anything besides stats and minor
> semantic tweaks?

yep, basically you can try to implement ENOMEM fallbacks (e.g.
through a collector cycle or the like) for embedded devices and stuff...
if you want caller information in a tracing tool, you need more than
malloc/free anyways, g_strdup/g_memdup come to mind immediately, there're
lots of other small utils that you'll need to override as well.
(i implemented a caller tracing mem-debugger for glib functions once).

> 
> --
> Grant Taylor - gtaylor picante com - http://www.picante.com/~gtaylor/
>     Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

---
ciaoTJ