-
Notifications
You must be signed in to change notification settings - Fork 12
Conversation
|
Well, for some reason, the build takes several hours for me with this change, most of that running the tests. I'm not sure why that is; this isn't exactly a slow laptop, but looking at the VM config, it only has 4GB of memory, so I might have forced it so swap. Either way, your numbers are much more reasonable. In any case, the automatic package tests pass, so all the same tests as before seem to be succeeding/failing. I say it's safe to turn on. Probably. |
|
I'm going to run this locally for a while and then cut a release. I might cut out some of the slower tests too. It's taking much longer on my laptop to build heh |
|
I looked at this some more, my timings above must have been before I added the flag to I also noticed that the profile test exclusions were only being applied to the I'll have another branch soon but tl;dr after fixing the excludes and removing profiled builds for the two debug builds it clocks in at ~28 minutes of overhead (essentially 2 test runs worth). I'm going to do some benchmarking and see if it's worth it. |
|
Here's the results of the performance tests I ran: https://i.fluffy.cc/xDgvxN1qW554V3q92GNPl7Gh1GxpWwKX.html Overall a 5-30% improvement on all of the benchmarks! |
|
As far as I understand, the static build is so the main interpreter doesn't depend on the shared library to keep it more self-contained. But that seems like a reason that's more relevant to Python as a part of a minimal bootstrapped OS. Though in general, I recommend keeping the changes to the upstream package to a minimum. Any change, however small it might seem, has a tendency to multiply once you have to keep any changes in sync between different Python versions and different Ubuntu versions. My experience has been that once you start changing things ("we don't need that part", "this could be solved better", "ooooh, I want that feature"), it ends up in a sort of maintenance nightmare. PGO is a pretty small change with an actual measurable payoff, so it should be fine. I just wanted to add my general thoughts. |
|
After trying these out for a while, I decided to upload them today. Strangely, both amd64 and i386 builds failed for only trusty. I'm building it locally and it has gotten past the place where it failed. I wonder if it's a bad builder host or if |
|
actually, if I log in I can click retry, trying that first :) |
|
Failed again in the same way, I guess I'll revert this for trusty. amd64i386 |
This adds about 14 minutes to the build on my machine (which seems reasonable?)
(these numbers are against
ubuntu/xenialbranch)(before):
real 12m30.493s(after):
real 26m46.294sNot all of the test modules pass during profiling for me
test_shutil test___all__The
test_shutilfailure appears to be due to docker:test___all__fails due to this:But this is ok, because of this line