[gst-devel] Rethinking --disable-gst-debug option in gstreamer configure script

Crane, Matt mattcrane at Tycoint.com
Mon Oct 4 19:49:29 CEST 2010


Gstreamer developers:

 

I am an engineer in a group that has developed a gstreamer application
that handles the recording of dozens of video streams in a single
server.  Recent load tests we've run with our application have revealed
that disabling debug logging during compile time via use of the
-disable-gst-debug option in the gstreamer configure script frees up
about 10% of the CPU cycles on our target hardware configuration (CPU
idle time with debugging enabled = ~50%; CPU idle time with debugging
disabled = ~60%).  While we would like to realize the performance
improvement that would come from disabling (much of the) debug logging,
we would still like to log ERROR and WARNING level messages on deployed
production systems.

 

Toward this end, we are thinking about changing the compile-time
configuration of debug logging to allow different levels of debug
enablement.  Instead of having a single -disable-gst-debug option, we
might like to  have a configure option like:
-gst-debug-logging=[disabled, warning, full].  In looking at the current
codebase,  -disable-gst-debug results in setting almost all of the
gstreamer debugging system function call macros to No-Op using
G_STMT_START{ }G_STMT_END.  In our proposed solution, we would
selectively set appropriate macros to No-Op to match the desired
gst-debug-logging parameter.  Going this route, it is thought that we
could maintain the availability of ERROR and WARNING messages without
keeping the overhead of higher level debug messages INFO, DEBUG, etc...

 

I wanted to float this proposal here on the devel list because, ideally,
we would like whatever idea we implement to be incorporated upstream
into the gstreamer project.  If any of the key contributors would like
to volunteer feedback on this idea (is it something you'd consider
incorporating into the project?  is there something about how you'd like
the scheme implemented?), we would greatly appreciate it.

 

Thank you for your time...

 

-Matt

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101004/c8378587/attachment.htm>


More information about the gstreamer-devel mailing list