Creating elements for the first time takes ages

[Ralph]

I wrote a WPF application using OSSBuild and C# bindings.
I notice that creating GStreamer elements for the first time using ElementFactory take ages.
Creating the following set of elements for the first time takes 9 seconds on a very fast machine:
- pipeline
- gnlcomposition
- gnlsource
- gnlfilesource
- audiotestsrc
- videotestsrc
Creating the same set for the second time takes just 120ms - that's absolutely fine.

All elements are created the same way:
Gst.Element element = Gst.ElementFactory.Make("elementtype");

I understand that creating an element for the first time requires finding the appropriate assembly, discovering some stuff and instantiating a few objects, but it should not be that slow!  The users of my application are complaining about the initialization time.

Is there any way of speeding up element creation?

[Edward Hervey]

Hi,

On Thu, 2012-06-21 at 07:36 -0700, Ralph wrote:

> I wrote a WPF application using OSSBuild and C# bindings.
> I notice that creating GStreamer elements for the first time using
> ElementFactory take ages.
> Creating the following set of elements for the first time takes 9 seconds on
> a very fast machine:
> - pipeline
> - gnlcomposition
> - gnlsource
> - gnlfilesource
> - audiotestsrc
> - videotestsrc
> Creating the same set for the second time takes just 120ms - that's
> absolutely fine.
>
> All elements are created the same way:
> Gst.Element element = Gst.ElementFactory.Make("elementtype");
>
> I understand that creating an element for the first time requires finding
> the appropriate assembly, discovering some stuff and instantiating a few
> objects, but it should not be that slow!  The users of my application are
> complaining about the initialization time.
>
> Is there any way of speeding up element creation?

  You should profile what takes up those 9s. How much does creating each
element take ? What is going on in the background ?

  A simple look at GStreamer debug logs might show the culprit.

  This should not happen, in case you're wondering.

>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Creating-elements-for-the-first-time-takes-ages-tp4655367.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ralph]

I profiled the execution of the following line:
    Gst.Element fileSource = Gst.ElementFactory.Make("gnlfilesource");


The result is:
    8037ms, 1 call  - Gst.ElementFactory.Make(String)
   

The critical method down the execution tree from Gst.ElementFactory.Make(String):
    8009ms, 5 calls  - Gst.Application.GstResolveType(GType, String)


The slowest methods called by Gst.Application.GstResolveType(GType, String)
    5208ms, 1272269 calls  - System.RuntimeType.IsDefined(Type, Boolean)
    2379ms, 2471 calls  - System.Reflection.Assembly.GetTypes


I'm confused...

[Edward Hervey]

On Thu, 2012-06-21 at 09:36 -0700, Ralph wrote:

> I profiled the execution of the following line:
>     Gst.Element fileSource = Gst.ElementFactory.Make("gnlfilesource");
>
>
> The result is:
>     8037ms, 1 call  - Gst.ElementFactory.Make(String)
>    
>
> The critical method down the execution tree from
> Gst.ElementFactory.Make(String):
>     8009ms, 5 calls  - Gst.Application.GstResolveType(GType, String)
>
>
> The slowest methods called by Gst.Application.GstResolveType(GType, String)
>     5208ms, 1272269 calls  - System.RuntimeType.IsDefined(Type, Boolean)
>     2379ms, 2471 calls  - System.Reflection.Assembly.GetTypes

 I'm not sure how those bindings work, but I'm going to say they are
dynamically generated (i.e. at runtime), and you've it the place where
it generates the bindings.

>
>
> I'm confused...
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Creating-elements-for-the-first-time-takes-ages-tp4655367p4655370.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Hoyt]

> I'm not sure how those bindings work, but I'm going to say they are dynamically generated (i.e. at runtime), and you've it the place where it generates the bindings.

I would advocate a shift to using the official gstreamer SDK. The provided build is a little more up-to-date. However, I don't believe the .NET bindings are provided...

Have you tried to build a similar pipeline using gst-launch? If so, how quickly does that work? It would help to isolate if it's the .NET or the C side of the house. Sometimes the initial call can take longer as the gstreamer registry is built.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Bruno Gonzalez-2]

I have also experienced the same. You can try several solutions:

 - Parallelize the creation of each pipeline element as much as possible (but be careful to profile this! If the slowdown is e.g. due to disk I/O, paralellizing probably won't be of any help)

 - Create a dummy pipeline just once (with all the required elements). This way, you force the load of its DLLs at the beginning of the program, and then each consequent pipeline creation is much faster.

 - Use a pool of pipelines ready to be configured and used (in my case 16, which is the largest amount of pipelines I'm having on screen at any given time). The pool is refilled with low priority so as not to disturb any other operation.

On Thu, Jun 21, 2012 at 7:44 PM, David  Hoyt <[hidden email]> wrote:
>> I'm not sure how those bindings work, but I'm going to say they are dynamically generated (i.e. at runtime), and you've it the place where it generates the bindings.
>
> I would advocate a shift to using the official gstreamer SDK. The provided build is a little more up-to-date. However, I don't believe the .NET bindings are provided...
>
> Have you tried to build a similar pipeline using gst-launch? If so, how quickly does that work? It would help to isolate if it's the .NET or the C side of the house. Sometimes the initial call can take longer as the gstreamer registry is built.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



--
Saludos,
     Bruno González

_______________________________________________
Jabber: stenyak AT gmail.com
http://www.stenyak.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ralph]

Bruno Gonzalez-2 wrote

I have also experienced the same. You can try several solutions:
 - Parallelize the creation of each pipeline element as much as possible
[...]

I'm already doing this - I'm creating all necessary pipelines when the program starts, but this results in 11 second total startup time (2 seconds for my application and 9 seconds for GStreamer) and that's on a very fast machine.  For users with netbooks and old laptops (majority of users, the software is mostly used in the field) this becomes unacceptably slow.  I try to cheat - I display a welcome screen with recently used files and a few other options and GStreamer is initialized in the background.  If the user spends those 9 seconds choosing the file to be opened he will not notice any delay, but when he clicks any of recently used files straight away (90% of cases), the initialization will be long (extremely long on slow machines).  Parallelizing does not help because it is creating the first element that takes 8 seconds, creating all other elements required for 6 pipelines takes less than 1 second.

David Hoyt wrote

I would advocate a shift to using the official gstreamer SDK. The provided build is a little more up-to-date. However, I don't believe the .NET bindings are provided...

I would be happy to start using GStreamer SDK, but as you noticed there are no .NET bindings.  This is real pain - accessing GStreamer from .NET is so buggy and unreliable, that I am not surprised there are just a few .NET applications using it and it is extremely difficult to find any documentation and examples on the net.  I have spent days trying to do things that "just work" in other languages, but for some reason do not work at all or crash when doing them using C# bindings.  What a shame, GStreamer is probably the most powerful video library ever created.

David Hoyt wrote

Have you tried to build a similar pipeline using gst-launch? If so, how quickly does that work? It would help to isolate if it's the .NET or the C side of the house. Sometimes the initial call can take longer as the gstreamer registry is built.

Executing "gst-launch.exe gnlfilesource" for the first time after system restart takes less than 3 seconds.  This is understandable, GStreamer initialization and searching for plugins takes a while.  All subsequent calls to gst-launch (also creating any other elements) are instantaneous.

Edward Hervey wrote

 I'm not sure how those bindings work, but I'm going to say they are
dynamically generated (i.e. at runtime), and you've it the place where
it generates the bindings.

What brings my attention is that System.Reflection.Assembly.GetTypes is called 2471 times.  The total number of GStreamer files I am using is 67 (35 files in bin folder, 30 plugins, gstreamer-sharp.dll and gstreamersharpglue-0.10.dll).  Are all assemblies in the system analyzed???  System.RuntimeType.IsDefined(Type, Boolean) is called 1.2 million times, that A LOT!

[Ralph]

Problem solved!!!

The problem existed on OSSBuild WinBuilds v0.10.7, Beta 04 with C# bindings.
Today I upgraded to OSSBuild-vs2010 2012.06.15 with .NET4 C# bindings and everything works smoothly and I don't have to wait for anything!   Hoooray!!!