<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> Gstreamer developers:<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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…<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Thank you for your time…<o:p></o:p> <o:p> </o:p> -Matt<o:p></o:p> <o:p> </o:p> </div> </body> </html>