[gst-devel] merging elements in plugins

Andy Wingo wingo at pobox.com
Wed Apr 13 15:55:38 CEST 2005


On Tue, 2005-04-12 at 20:05 +0200, Ronald S. Bultje wrote:
>[Thomas: please use reply-to-list]

Tru dat. It makes evolution happier.

/* GStreamer
 * Copyright (C) <1999> Erik Walthinsen <omega at cse.ogi.edu>

Ronald!!!!! Claim your birthright!!!

>Attached speed.c tests local plugins (which is the same as having
>multiple elements in one plugin;

Er... no. For a number of reasons:

1) having them in the executable means they're not dlopened at all,
which means you're not testing the effect of one dlopen versus many

2) gnomevfssrc links to external libraries, which is not the case under

3) gnomevfssrc calls gnome_vfs_init(), which ends up dlopening a few .so
files on its own

>The thing is, it's effortless (it's a simple
>Makefile.am change), so why not?

I'd totally be with you if I thought it made a difference. I don't, but
that's a hunch. If you're right I'll change sides. Soooooo, if it's so
effortless (wink), do it and see if we get an improvement. (I suspect
you'll find it's not so effortless, but hey, gst-plugins-base is

Better yet, profile your sooper-sekret app to show what the bottlenecks
are. Post that data somewhere so people can analyze it. Perhaps under
NDA ;-)

I think timing functions is probably a bit misleading though, because of
the lazy resolving. I'd like to change that to do RTLD_NOW resolving, if
only to prevent symbol lookups while in a processing loop. (You have to
pay for just about all of that cost before dataflow anyway, might as
well pay for it in the beginning so you can minimize paused->playing

Peace and potatos,
Andy Wingo

More information about the gstreamer-devel mailing list