docs/random/wtay/performance

   1 Fixing Performance
   2 ------------------
   3
   4 1) Observations
   5
   6  The following observations are made when considering the current (17/11/2004)
   7  problems in gstreamer.
   8
   9  - startup time.
  10    Most of the time is spend in reading the xml registry. Several methods exist
  11    for not using a registry (see testsuite/plugin/).
  12    Since registries are pluggable, one can also write a binary registry which
  13    should significantly reduce the size and the load time.
  14
  15  - Performance in state changes
  16    State changes are pretty heavy currently because negotiation happens at
  17    each state change. The PAUSED->PLAYING state change in particular is
  18    too heavy and should be made more 'snappy'.
  19
  20  - Performance in data passing.
  21    Too much checking is done in the push/pull functions. Most of these checks
  22    can be performed more efficiently in the plugins, like checking if the
  23    element is sufficiently negotiated. The discont event 'invent' hack used
  24    for fixing the synchronisation has to go away.
  25
  26    We also propose a get_range based method for pads so that random-access
  27    in file-based sources can happen more efficiently (typical for muxers).
  28
  29  - Scheduling overhead.
  30    The current default opt scheduler has extensive data-structures and does
  31    uses fairly complicated algorithms for grouping and scheduling elements.
  32    This has performance impact on pipeline constructions and pipeline
  33    execution.
  34
  35  - Events in dataflow.
  36    Because events are put inside the dataflow, a typical chain function has
  37    to check if the GstData object is an event of a buffer.
  38
  39
  40 2) Proposed solutions
  41
  42  - startup time.
  43    Volunteers to implement a binary registry?
  44
  45  - The changes listed in the separate document 'threading' will greatly
  46    reduce the number of negotiation steps during state changes. It will
  47    also reduce the latency between PAUSED<->PLAYING since it basically
  48    involves unlocking a mutex in the sinks.
  49
  50  - adding return values to push/pull will offload some checks to the plugins
  51    that can more efficiently and more accuratly handle most error cases.
  52    With the new sync model in 'threading' it is also not needed to have
  53    the 'invented' events in the pull function.
  54
  55  - The following scheduling policies should be made possible for pads:
  56
  57     1) get_range <-> pull-range-based
  58     2) get       <-> pull based
  59     3) push      <-> chain-based
  60
  61    The scheduling policies are listed in order of preference. A pad should
  62    export what scheduling it supports and the core will select what
  63    scheduling method to use. It is possible for a pad to support more than
  64    one scheduling method.
  65
  66    It is possible that two elements cannot connect when they do not support
  67    compatible scheduling policies. We require that pull-based pads also
  68    support the chain based methods, at minimal, using a helper function to
  69    queue a buffer and that get-based pads also support a push based implementation.
  70
  71  - With the changes listed in 'threading' the scheduler will be a lot more
  72    simple since it does not have to keep track of groups and connected
  73    elements. Starting and scheduling the pipeline will be a matter of
  74    starting the source/loop GstTasks and they will from there on take
  75    over.
  76
  77  - move events out of the dataflow. Different methods will be used to
  78    send/receive events. This will also remove some of the checks in
  79    the push/pull functions. Note that plugins are still able to serialize
  80    buffers and events because they hold the streaming lock.
  81
  82 3) detailed explanation
  83
  84   TO BE WRITTEN
  85