[gst-devel] merging elements in plugins

[Andy Wingo]

Yo,

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
consideration

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
smaller.)

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
time.)

Peace and potatos,
-- 
Andy Wingo
http://wingolog.org/