GNOME Bugzilla – Bug 161991
gst_init is slow
Last modified: 2005-04-12 15:01:48 UTC
$ ./speed Time: 0:00:02.775234000 $ cat speed.c #ifdef HAVE_CONFIG_H #include "config.h" #endif #include <sys/time.h> #include <gst/gst.h> gint main (gint argc, gchar *argv[]) { struct timeval t1, t2; /* init */ gettimeofday (&t1, NULL); gst_init (&argc, &argv); gettimeofday (&t2, NULL); g_print ("Time: %" GST_TIME_FORMAT "\n", GST_TIME_ARGS ((((gint64) t2.tv_sec * 1000000 + t2.tv_usec) - ((gint64) t1.tv_sec * 1000000 + t1.tv_usec)) * 1000)); return 0; } $ That is very painful. More than 2,5s for gst_init()... Thank god, we have callgrind. ~34% is spent in init_pre() and ~66% in init_post(). Pretty much all of this is registry parsing. Something tells me this is due to caps parsing. Here's what happens if I change the caps of ffmpeg's raw video pad templates to a simpler form (see attached patch): $ ./speed Time: 0:00:01.747114000 Now imagine the rest yourself... Can this be made faster?
Created attachment 35130 [details] see text
Another thing that might be interesting is to only parse caps once they are requested, and keep them in text form until then. We mostly don't actually use all of the caps on all of the pad templates anyway.
Are you running uninstalled?
Yes.
ignore my last comment. Benjamin and I wanted to make pad templates use caps strings (actually, use GstStaticCaps), but it requires an ABI change because of the GST_PAD_TEMPLATE_CAPS() macro. I'm not sure what benefit this would be, since the first attempt to search for an element by sinkpad caps would convert all the strings. If one was clever, perhaps not all the strings would be converted, though.
decodebin does only sinkpads (=~0.5) of decoders, parsers and demuxers (=~0.50), which is only 25% of total. If we can save an additional 75% of, say, 1.5 out of 1.75 seconds, then that's more than worth it, because it reduces startup time to less than 1.0s.
Created attachment 38245 [details] [review] part #1 This patch implements a libxml-based registry reader. Code mostly by Benjamin, I simply converted it into something where it works both with and without libxml and fixed some parsing errors and memory leaks to make it just work. The writing code is duplicated over two files, I should fix that. Laptop: 0.35s->0.18s, Desktop: 0.80s->0.43s (fixed testcases with the same registry, average of five times with testcase given above and file cached in memory to prevent harddisk spinup time from influencing this). So roughly a gain of 50%. this patch does not touch registry implementation or ABI, so will work for 0.8. I'm working on a second patch doing what Dave says for 0.9 (converting to staticpadtemplates/staticcaps).
Created attachment 38255 [details] [review] part #2 This patch is to be installed on top of patch #1. It lets GstElementFactory use static pad templates (and thus static caps). It decreases init time from 0.18s to 0.045s on my laptop (I didn't test it on my desktop), thereby cutting off almost 90% of the initial init time (0.35s, see patch #1).
You also need some compile fixes to your registry for #2, but my patches are intermingled. You'll figure out yourself if you play with the patch.
Created attachment 38262 [details] [review] update This one includes the gstlibxmlregistry.c changes.
Committed, setting version to 0.8.10 because it's mostly included there already.