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

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #4 from Maarten Bosmans <mkbosmans at gmail.com> 2009-12-22 10:54:55 UTC ---
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.

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.

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?

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?

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