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

[Stefan Kost]

Am 04.10.2010 20:49, schrieb Crane, Matt:
> 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 if some uses of GST_ERROR should become a GST_ELEMENT_ERROR instead
(likewise for the warnings). Do you have some example of messages that you would
like to still get with debug logging turned off.

Stefan

>  
> 
> 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
> 
>  
> 
> 
> 
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security 
> easier or more difficult to achieve? Read this whitepaper to separate the 
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel