This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients Nitapol, lukasz.langa, ned.deily, rhettinger, ronaldoussoren, vstinner
Date 2019-08-26.05:59:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1566799146.99.0.729184805555.issue36205@roundup.psfhosted.org>
In-reply-to
Content
Raynmond:

> Something in the release build process is triggering this behavior (perhaps PGO).

The difference is explained in msg33731. When 3.7+ is built on macoS 10.11.x+ and earlier, clock_gettime is not available and the PEP 564 refactored code falls back to using getrusage as it did correctly prior to 3.7.  But there seems to be a bug in the 3.7 refactored fallback code that gives a result about twice as big as seen in the results of either the proposed test case in PR 12287 or, more simply, the test code in the StackOverflow issue cited above (https://stackoverflow.com/questions/55008397/python-3-5-vs-3-7-process-time).  The pre-PEP 564 code in 3.6.x and earlier works correctly regardless on what version of macOS Python was built. 

Since this problem has apparently been around since 3.7.0 with the implementation of PEP 564, it should not act as a release blocker for 3.8.0.  But it *really* needs to be fixed.

Victor, could you please find some time to look at this?  Thanks!
History
Date User Action Args
2019-08-26 05:59:07ned.deilysetrecipients: + ned.deily, rhettinger, ronaldoussoren, vstinner, lukasz.langa, Nitapol
2019-08-26 05:59:06ned.deilysetmessageid: <1566799146.99.0.729184805555.issue36205@roundup.psfhosted.org>
2019-08-26 05:59:06ned.deilylinkissue36205 messages
2019-08-26 05:59:06ned.deilycreate