Re: [gst-devel] On the plugin cache

[Jan S. <th...@no...>]

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 [1] 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 :)

J.
-- 
Jan Schmidt <th...@no...>