Over in Ubuntu, we've gotten reports about some performance regressions in
Python 2.7 when moving from Trusty (14.04 LTS) to Xenial (16.04 LTS).
Trusty's version is based on 2.7.6 while Xenial's version is based on 2.7.12
with bits of .13 cherry picked.
We've not been able to identify any change in Python itself (or the
Debian/Ubuntu deltas) which could account for this, so the investigation has
led to various gcc compiler options and version differences. In particular
disabling LTO (link-time optimization) seems to have a positive impact, but
doesn't completely regain the loss.
Louis (Cc'd here) has done a ton of work to measure and analyze the problem,
but we've more or less hit a roadblock, so we're taking the issue public to
see if anybody on this mailing list has further ideas. A detailed analysis is
available in this Google doc:
The document should be public for comments and editing.
If you have any thoughts, or other lines of investigation you think are
worthwhile pursuing, please add your comments to the document.
Last weeks, I worked on a new tool to bisect failing tests because
it's painful to bisect manually reference leaks (I remove as much code
as possible until the code is small enough to be reviewable manually).
See the bisect_test.py script attached to this issue:
With the help of Louie Lu, I added new --list-cases option to "python
-m test", so you can now list all test cases and write it into a text
./python -m test --list-cases test_os > tests
I also added a new --matchfile option, to filter tests using a text
file which contains one pattern per line:
./python -m test --matchfile=tests test_os
fnmatch is used to match test names, so "*" joker character can be
used in test names.
My bisection tool takes a text file with the --matchfile format (one
pattern per line) and creates a random subset of tests with half of
the tests. If tests still fail, use the subset. Otherwise, create a
new random subset. Loop until the subset contains a single test
(configurable threshold, -n command line option).
The long term plan is to integrate the bisection feature directly into regrtest.
Right now, my script is hardcoded to bisect reference leak bugs, but
it should be easy to modify it to bisect other test issues like test
creating files without removing it ("ENV_CHANGED" failure in
For example, a core file is dumped when running test_subprocess on
But I'm unable to reproduce the issue on my FreeBSD. It would be nice
to be able to automate the bisection on the buildbot directly.
--list-cases and --matchfile options are now available in 2.7, 3.5,
3.6 and master (3.7) branches.
TODO: doctest tests are only partially supported, see:
Our buildbots are now even more stable than in my previous buildbot report.
Many random failures have been fixed, even if there are still many
rare random failures (most of them are related to multiprocessing).
Search for issues created by "haypo" (me!) with the Component "Tests"
to see all remaining issues. I'm trying to open an issue for *each*
buildbot failure! So yeah, we have a long list of 44 open issues!
Correct me if I'm wrong, but, for the first time, *all reference
leaks* have been fixed on *all branches* (2.7, 3.5, 3.6 and master),
on *Linux and Windows*! Before, we mostly focused on the master branch
(called "default" in Mercurial) on Linux.
I also started to fix a few "memory block" leaks, most (or all?) of
them should also be fixed (on all branches, on Linux and Windows).
A new policy has been decided (on python-committers): if a commit
breaks too many buildbots and cannot fixed easily nor quickly, the
commit will be reverted, just to keep our buildbots "green". It
doesn't mean that the commit will be rejected forever. It's a
practical solution to give more time to write a proper fix, take time
to review it, and not have to be stressed to fix buildbots "ASAP".
Moreover, keeping green buildbots all the time allows to catch
regressions more quickly, which ease debug in many ways.
You have be warned! Now I will not hesitate to revert your change if
you break my little buildbots ;-)
I mostly care of Linux, Windows, macOS and FreeBSD (10 and CURRENT).
Breaking other platforms is less important, since other platforms
already have issues, but not enough developers interested to fix them.
Obviously, I'm interested in keeping more buildbots green, if someone
shows up and help me to fix remaining issues!
2017-06-29 23:34 GMT+02:00 Rob Boehne <robb(a)datalogics.com>:
> I¹m new to the list, and contributing to Python specifically, and I¹m
> interested in getting master and 3.6 branches building and working
> ³better² on UNIX.
> I¹ve been looking at a problem building 3.6 on HP-UX and see a PR was
> merged into master, https://github.com/python/cpython/pull/1351 and I¹d
> like to see it applied to 3.6. I¹m happy to create a PR with a
> cherry-picked commit, and/or test.
Sure, this change can be backported to 3.6, maybe also to 3.5. But
hum, I may suggest to first focus on the master branch and fix most
HP-UX issues, before spending time on backport. I would prefer to see
most tests of the important modules pass on HP-UX (ex: test_os).
For a backport, you can directly comment http://bugs.python.org/issue30183
I was looking at some `dis` output today, and I was wondering if anyone has
investigated optimizing Python (slightly) by adding special-case bytecodes
for common expressions or statements involving constants?
For example, I (and, based on a quick grep of the stdlib, many others)
write "x is None" and "x is not None" very often. Or "return True" or
"return None" or "return 1" and things like that. These all expand into two
bytecodes, which seems pretty non-optimal (LOAD_CONST + COMPARE_OP or
LOAD_CONST + RETURN_VALUE). It seems we could get an easy speedup for these
common cases by adding a peephole optimization and some new opcodes (maybe
COMPARE_IS_SMALL_CONST and RETURN_SMALL_CONST for these cases).
I'm not proposing to do this yet, as I'd need to benchmark to see how much
of a gain (if any) it would amount to, but I'm just wondering if there's
any previous work on this kind of thing. Or, if not, any other thoughts
before I try it?