[gstreamer-bugs] [Bug 604965] Gst.Application.GstResolveType is useless, or just very slow at best

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Dec 23 01:16:07 PST 2009


https://bugzilla.gnome.org/show_bug.cgi?id=604965
  GStreamer | gst-sharp | git

--- Comment #5 from Sebastian Dröge <slomo at circular-chaos.org> 2009-12-23 09:16:01 UTC ---
(In reply to comment #4)
> I did some profiling. Initializing a pipeline with a playbin and a sink results
> in 4 calls to GstResolveType.
> 
> GstDshowVideoSink  2250 ms
> GstBus              740 ms
> GstMessage          730 ms
> GstPlaySink         710 ms
> 
> None of which can be resolved to a managed type.

Yeah, GstBus/GstMessage should never get into our type resolver at all :)

> Skipping mscorlib and all assemblies starting with "System." lowers the time to
> 1600ms for the first and 100ms for subsequent calls.
> 
> The remaining time is mainly for Assembly.GetTypes(), which is pretty slow
> (800ms for gtk-sharp alone, it has over 1800 types) the first time, but .Net
> seems to do come caching itself, because it is a lot faster for further calls
> on the same assembly.
> 
> I implemented caching using a Dictionary to store all types with a
> GTypeNameAttribute and got <15ms for the last three calls, but the first is
> still over 1500ms.

Sounds good, yes.

> So one way to avoid the overhead is to make sure all the types are known and in
> a assembly that is checked for types first. I'll look into why GstResolveType
> is called for GstBus/GstMessage. I don't know what a GstPlaySink is. Are you
> willing to accept bindings for GstDshowVideoSink, or do you want to leave
> Bad/Ugly alone for now?

GstPlaySink is an internal element of playbin2 which is exported since 0.10.25.
Adding bindings for this is a good idea, same for the dshow sink.

> Another option would be to only load assemblies which (eventually) depend on
> gstreamer-sharp. This would avoid calling GetTypes() on mscorlib, System.* and
> gtk-sharp for example.
> Am I right in thinking that any assembly that would be useful to 
> Gst.Application.GstResolveType  would have to depend on gstreamer-sharp?

Yes because they need Gst.Element or Gst.TypeFind or Gst.Index at least. Good
idea :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the Gstreamer-bugs mailing list