Le vendredi 26 avril 2019, 21:13:22 SAST Julian Taylor a écrit : Hi all, It seems that my message was misinterpreted, so let me clarify a few things.
I'm not saying that increasing the size of the binary is a bad thing, specially if there are lots of improvements that caused this increase. My message was just a note to be sure that bandwidth availability is not forgotten, as it's fairly easy (I'm guilty of that myself) to take for granted that downloads will always be fast and hassle free. Concerning the environments where it matters, I currently live in South Africa, and even if things are improving fast in terms of bandwidth availability, there is still a long way for people to get fast access at their houses for a fee that is accessible. So I'd say that environments where the size of binaries has no impact are the clear minority here. That said, as I've raised the issue I wanted, and you are aware of it, I do not see a reason to increase the size of this thread. Cheers, Éric. > Hi, > We understand that it can be burden, of course a larger binary is bad > but that bad usually also comes with good, like better performance or > more features. > > How much of a burden is it and where is the line between I need twice as > long to download it which is just annoying and I cannot use it anymore > because for example it does not fit onto my device anymore. > > Are there actual environments or do you know of any environments where > the size of the numpy binary has an impact on whether it can be deployed > or not or where it is more preferable for numpy to be small than it is > to be fast or full of features. > > This is interesting to us just to judge on how to handle marginal > improvements which come with relatively large increases in binary size. > With some use case information we can better estimate were it is > worthwhile to think about alternatives or to spend more benchmarking > work to determine the most important cases and where not. > > If there are such environments there are other options than blocking or > complicating future enhancements, like for example add a compile time > option to make it smaller again by e.g. stripping out hardware specific > code or avoiding size expensive optimizations. > But without concrete usecases this appears to be a not something worth > spending time on. > > On 26.04.19 11:47, Éric Depagne wrote: > > Le vendredi 26 avril 2019, 11:10:56 SAST Ralf Gommers a écrit : > > Hi Ralf, > > > >> Right now a wheel is 16 MB. If we increase that by 10%/50%/100% - are we > >> causing a real problem for someone? > > > > Access to large bandwidth is not universal at all, and in many countries > > (I'd even say in most of the countries around the world), 16 Mb is a > > significant amount of data so increasing it is a burden. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -- Un clavier azerty en vaut deux ---------------------------------------------------------- Éric Depagne _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
