I wouldn't be so sure, this apply to non-optimized code, but if you enable optimizations in your compiler together with debug symbols producing, some optimizations may need to be disabled, which may result even in worse performance. <ref> 1 </ref>
But I don't really know how much is maria db depending on compiler optimizations so maybe this indeed is not a big problem. But from my own experience replacing debug build with optimized build has a significant performance improvements. [1] - http://stackoverflow.com/questions/2880025/why-do-debug-symbols-so-adversely-affect-the-performance-of-threaded-application don't be confused by the wrongly asked question - the guy indeed had main problems because of profiling but if you read the table it say: Optimized no threading: 0m4.864sOptimized threading: 0m2.075s Debug no threading (no-pg): 0m10.428sDebug threading (no-pg): 0m4.045s that means it cause performance issues even when profiling is disabled. On Thu, Feb 14, 2013 at 5:14 PM, Mark Bergsma <[email protected]> wrote: > > On Feb 14, 2013, at 5:02 PM, Petr Bena <[email protected]> wrote: > > > Keeping debug symbols in binaries will result in poor performance, or it > should > > That's bollocks. It results in a larger binary _on disk_. The symbol table > isn't even loaded into memory and doesn't affect performance. > > Debug information is *highly useful* in a production setup, and we try to > run all our core applications with it so we have a chance to debug issues > when they occur. > > I think the only reason distributions omit debug information is to save > disk space. > > -- > Mark Bergsma <[email protected]> > Lead Operations Architect > Wikimedia Foundation > > > > > > _______________________________________________ > Labs-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/labs-l >
_______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
