[gst-devel] On the plugin cache

[Jan Schmidt]

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.

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.

J.
-- 
Jan Schmidt <thaytan at noraisin.net>