After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 161991 - gst_init is slow
gst_init is slow
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Low normal
: 0.8.10
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-12-22 15:27 UTC by Ronald Bultje
Modified: 2005-04-12 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
see text (820 bytes, text/plain)
2004-12-22 15:28 UTC, Ronald Bultje
  Details
part #1 (41.55 KB, patch)
2005-03-04 14:47 UTC, Ronald Bultje
committed Details | Review
part #2 (12.28 KB, patch)
2005-03-04 17:07 UTC, Ronald Bultje
none Details | Review
update (15.70 KB, patch)
2005-03-04 18:44 UTC, Ronald Bultje
none Details | Review

Description Ronald Bultje 2004-12-22 15:27:45 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?
Comment 1 Ronald Bultje 2004-12-22 15:28:34 UTC
Created attachment 35130 [details]
see text
Comment 2 Ronald Bultje 2004-12-22 15:32:13 UTC
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.
Comment 3 David Schleef 2004-12-22 22:16:21 UTC
Are you running uninstalled?
Comment 4 Ronald Bultje 2004-12-22 22:32:52 UTC
Yes.
Comment 5 David Schleef 2004-12-22 22:57:37 UTC
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.
Comment 6 Ronald Bultje 2004-12-23 00:13:23 UTC
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.
Comment 7 Ronald Bultje 2005-03-04 14:47:40 UTC
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).
Comment 8 Ronald Bultje 2005-03-04 17:07:06 UTC
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).
Comment 9 Ronald Bultje 2005-03-04 17:27:31 UTC
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.
Comment 10 Ronald Bultje 2005-03-04 18:44:35 UTC
Created attachment 38262 [details] [review]
update

This one includes the gstlibxmlregistry.c changes.
Comment 11 Ronald Bultje 2005-04-12 15:01:48 UTC
Committed, setting version to 0.8.10 because it's mostly included there already.