<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 1:59 PM Andrea Griffini <<a href="mailto:agriff@tin.it">agriff@tin.it</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>does it have any sense for a linux distribution (arch to be specific) to provide default Python package compiled with valgrind support? I thought this flag was just about silencing false positives generated by valgrind (in other words a workaround for "bugs" of another software) and useful only when developing Python itself or C extensions.</div></div></blockquote><div><br></div><div>It's not really our place to say if it makes sense for Arch to compile with valgrind flags turned on. It really depends on how they use Python in their Linux distribution and what their own goals are.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The same distribution also compiles by default to a shared library and this has a quite noticeable impact on performance on x64 (surprisingly for me) for CPU bound processing; in a few test cases I measured valgrind+shared Python running at 66% the speed of plain ./configure && make Python on my system. Is this setting reasonable for general users?</div></div></blockquote><div><br></div><div>Once again, it all depends on how Arch uses Python.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>If they are good defaults, why aren't them the default?</div></div></blockquote><div><br></div><div>That's a question for Arch Linux and not us. </div></div></div>