[gst-devel] On the plugin cache
thaytan at noraisin.net
Fri Nov 7 21:03:54 CET 2008
On Fri, 2008-11-07 at 14:42 -0500, Behdad Esfahbod wrote:
> Jan Schmidt wrote:
> > On Wed, 2008-11-05 at 21:51 -0500, Behdad Esfahbod wrote:
> >> Hi,
> >> So, I blamed the gst plugin cache in my blog entry  for taking some 35ms on
> >> every gst-using app startup. It's only fair that I follow up with how I think
> >> this should be fixed.
> > I have a quilt stack that starts to address some of these problems. It
> > has some bugs, so I'm not ready to commit it yet, and it doesn't (yet)
> > handle stat'ing plugin directories to shortcut re-scanning.
> > What I have so far replaces the fork+stat method below with a version
> > that stats, and g_spawns a helper when discovering an out of date
> > plugin. The helper loads the plugin (or crashes) and feeds the details
> > back to the parent, and the parent incorporates the new plugin info into
> > it's registry. When it's all done, the parent rewrites the registry
> > cache file if needed.
> Interesting. Though that would do a fork per plugin?
No, it forks a helper the first time and then has a little protocol back
and forth across the fd's.
> > That improves the scanning procedure, which is obviously good - it
> > avoids forking unnecessarily, and avoids the cost of reloading the
> > registry cache in the parent. It's not yet clear to me how much that
> > saves though. From some tests, the cost of the fork is pretty low
> > (10ms), which implies that the bulk of the time you saw in your graph is
> > spent elsewhere. I suspect a big chunk of it may be the cost of creating
> > (here) 700 odd Plugin/Element/other GObject instances, and that's harder
> > to eliminate.
> I suspect creating GObject's is taking much of that time, though I have not
> measured. I'm more suspicious of the stats.
did you mean "isn't" taking much of that time?
I think we need some more measurements :)
Jan Schmidt <thaytan at noraisin.net>
More information about the gstreamer-devel