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

[Owen Taylor <otaylor redhat com>]

Grant Taylor <gtaylor picante com> writes:

> >>    state machine scheduling.  I added a g_source_detach, which I use
> > i don't remember the details, but owen had good reasons for not
> > offering source detachment (at least at this point).
> 
> It was trivial to implement, but gmain is not really set up for
> frequent context changes, so performance gets pretty awful if you
> often detach things.  Either you start the loop over, or you rummage
> all over the place trying to adjust context state to where it won't
> run that source anymore in the existing iteration.  Both options
> sucked.

Detaching breaks assumptions that the main loops uses for thread
safety. It's not at all trivial once you add the threaded aspect.
 
> GMain seems to concentrate on generality, which IMHO isn't as useful
> as specifically implementing most of the actually existing types of
> event sources (fds, timers, signals, children, toolkits, etc) in a
> more tightly coupled way.  Extensibility should be offered in the form
> of hooks into various points in the loop, not via the ability to add
> further items to a very inefficient generic list of event objects.
> 
> Ask your users to raise their hands if they have implemented a
> GSource.  I guarantee you can count them on a hand or two.  

Maybe three hands. But that's not really the point. How many users
have used a GSource not in GLib? Every programmer using GTK+. The
original idea of GSource was to allow integration of the X loop into
the GLib main loop; if that was the only use ever, it would have been
useful. As it turns out people have written a small number of sources
for things like unix signals and customized IO handling.

But just as importantly, having a single abstraction for everything in
the main loop makes a big difference for implementing:

 - Priorities
 - Reentrancy
 - Thread safety
 - Memory management
 
in a consistent way for all event source types. If everything
was special cased and I had a big "insert-gdk-stuff-here"
hook, I'd have spent more time writing the main loop code
and have less confidence in the correctness of the result.

> The generality is not useful, and impairs the speed of the most
> frequently run code in every GTK program.  Even small overheads
> matter here; all the gratuitous function calls for figuring out
> source readiness etc are measurable when they really shouldn't even
> exist.

I certainly disagree about the usefulness. As for performance -

 a) I've never seen the main loop show up on a profile
    of a GTK+ app. For a typical GTK+ app, it's one iteration - 
    a handful of function calls - per X event, which is
    not the expensive part of event handling.

 b) I did some benchmarking on the GLib-2.0 mainloop, and
    for small numbers of sources performance was quite
    comparable to the fastest I could write the loop straight
    to the X API. (Forget the exact numbers, significantly
    less than a 50% slowdown, I believe; see tests/timeloop.c
    and tests/timeloop-basic.c in the GTK+ distribution.)

Now, if you have hundreds sources, then yes, performance isn't going
to be that great because it iterates through all the sources every
time. A lot of that is just the nature of the way poll() and/or
select() works on Unix. Some of it could be helped by using different
data structure. Some of it could probably be helped by having a "hint
flags" to allow GIOChannel to bypass the prepare()/check() callbacks.

Anyways, the basic design of the main loop isn't really changeable at
this point, though elaboration for efficiency for large number of
sources is probably still possible for future GLib releases if that
turns out to be a problem. I understand that it isn't going to be
everybody's cup of tea or fit every application perfectly.
I'm pretty happy with it.

Regards,
                                        Owen