Re: [gst-devel] On the plugin cache

[Behdad E. <be...@be...>]

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?

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

behdad

> J.