> On Jun 12, 2017, at 6:10 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Mon, Jun 12, 2017, at 10:23 PM, Donald Stufft wrote: >> because it allows the front ends more flexibility in how they use the wheels > > I don't get this? Why is it more flexible?
I went into some detail here: https://mail.python.org/pipermail/distutils-sig/2017-June/030684.html <https://mail.python.org/pipermail/distutils-sig/2017-June/030684.html> > >> and allows us to avoid doing work, making the process involved faster for >> everyone. > > This is true so long as backends build a directory and then skip zipping it > up. If backends are building a zip file and then unpacking it (which, from > what Daniel and I have described, may be common), then for tasks which want a > zip file, you're now unpacking and repacking it. We can’t force backends (or frontend) to implement things in the most performant way, we can only provide the tools to make it possible for them to do so. They could just as easily choose to add a time.sleep(5) just for kicks too. However, even in that case where the author of a backend tool chooses to implement it less efficiently than they possibly could, that’s fine because in one of the cases we’re in no worse off a condition than we would be if the backend was doing the zipping and in two conditions we are worse off, but they’re also conditions where the work is done once and then shared many times, so the amortized cost is relatively low anyways. > > So it hinges both on what backends do and on what tasks are common for > frontends using this interface. You might assume that the most common task > will be installation, which uses the files unpacked. But most installs will > use a pre-built wheel, so it's not obvious to me that the typical use of the > build interface will be to install a package. > No, I assume that for 2/3 of the cases *today* it basically does not matter if the front end or the backend does the ziping, the wiping is going to happen either way. For 1 of those 2/3 cases there is a possibility of changing that in the future to optimize a common path more (via the wheel cache) where moving the zipping into the front end shaved off time. For 1/3 of those cases today it will cut off processing time. So to sum up: Today: 1/3 of the cases will be faster, 2/3 of the cases it will make no difference. Possible Future: 2/3 of the cases will be faster, 1/3 of the cases it will make no difference. There is basically no benefit to having the backend do it, there is no case where it is faster to do so unless you assume a modern CPU with an ancient and slow hard drive to the point that copying a file is significantly slower than compressing it. Just for kicks I went and did a quick test on pip, when generating a wheel, ~50% of the time taken running ``python setup.py bdist_wheel`` on my computer is taken up by compressing the file and another ~25% of that time is taken up by decompressing the file again. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
