<p dir="ltr"><br>
</p>
<p dir="ltr"></p>
<p dir="ltr">On Mon, Aug 24, 2015, 11:19 PM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</p>
<blockquote><p dir="ltr">On 25 August 2015 at 05:52, Gregory P. Smith <<a href="mailto:greg@krypto.org">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)</p>
<p dir="ltr">Having the "production ready" make target be "make profile-opt"<br>
doesn't strike me as the most intuitive thing in the world.</p>
<p dir="ltr">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>
</p>
</blockquote>
<blockquote><p dir="ltr"><br>
Regards,<br>
Nick.</p>
<p dir="ltr">--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@</a><a href="mailto:ncoghlan@gmail.com">gmail.com</a>   |   Brisbane, Australia<br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>
<p dir="ltr">Agreed. Also, printing a message out at the end of a default make all build suggesting people use make production for additional performance instead might help advertise it.</p>
<p dir="ltr">make install could possibly depend on make production as well?<br>
</p>