[Labs-l] [Wikitech-l] Maria DB

Petr Bena benapetr at gmail.com
Thu Feb 14 16:49:21 UTC 2013


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 <mark at wikimedia.org> wrote:

>
> On Feb 14, 2013, at 5:02 PM, Petr Bena <benapetr at gmail.com> 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 <mark at wikimedia.org>
> Lead Operations Architect
> Wikimedia Foundation
>
>
>
>
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/labs-l/attachments/20130214/df89833d/attachment-0001.html>


More information about the Labs-l mailing list