<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 24 Aug 2015 at 23:19 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25 August 2015 at 05:52, Gregory P. Smith <<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>> wrote:<br>
> What we tested and decided to use on our own builds after benchmarking at<br>
> work was to build with:<br>
><br>
> make profile-opt PROFILE_TASK="-m test.regrtest -w -uall,-audio -x test_gdb<br>
> test_multiprocessing"<br>
><br>
> In general if a test is unreliable or takes an extremely long time, exclude<br>
> it for your sanity.  (i'd also kick out test_subprocess on 2.7; we replaced<br>
> subprocess with subprocess32 in our build so that wasn't an issue)<br>
<br>
Having the "production ready" make target be "make profile-opt"<br>
doesn't strike me as the most intuitive thing in the world.<br>
<br>
I agree we want the "./configure && make" sequence to be oriented<br>
towards local development builds rather than highly optimised<br>
production ones, so perhaps we could provide a "make production"<br>
target that enables PGO with an appropriate training set from<br>
regrtest, and also complains if "--with-pydebug" is configured?<br></blockquote><div><br></div><div>That's an interesting idea for a make target. It might help get the visibility of PGO builds higher as well. </div></div></div>