<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 27, 2019 at 8:04 PM Éric Depagne <<a href="mailto:eric@depagne.org">eric@depagne.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le vendredi 26 avril 2019, 21:13:22 SAST Julian Taylor a écrit :<br>
Hi all, <br>
<br>
It seems that my message was misinterpreted, so let me clarify a few things.<br>
<br>
I'm not saying that increasing the size of the binary is a bad thing, <br>
specially if there are lots of improvements that caused this increase.<br>
<br>
My message was just a note to be sure that bandwidth availability is not <br>
forgotten, as it's fairly easy (I'm guilty of that myself) to take for granted <br>
that downloads will always be fast and hassle free.<br></blockquote><div><br></div><div>Thanks Eric, your point is clear and we definitely won't forget to consider users on older hardware or behind slow connections.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Concerning the environments where it matters, I currently live in South Africa, <br>
and even if things are improving fast in terms of bandwidth availability, <br>
there is still a long way for people to get fast access at their houses for a <br>
fee that is accessible. So I'd say that environments where the size of <br>
binaries has no impact are the clear minority here.<br>
<br>
That said, as I've raised the issue I wanted, and you are aware of it, I do not <br>
see a reason to increase the size of this thread.<br>
<br>
Cheers, <br>
Éric.<br>
<br>
> Hi,<br>
> We understand that it can be burden, of course a larger binary is bad<br>
> but that bad usually also comes with good, like better performance or<br>
> more features.<br>
> <br>
> How much of a burden is it and where is the line between I need twice as<br>
> long to download it which is just annoying and I cannot use it anymore<br>
> because for example it does not fit onto my device anymore.<br>
> <br>
> Are there actual environments or do you know of any environments where<br>
> the size of the numpy binary has an impact on whether it can be deployed<br>
> or not or where it is more preferable for numpy to be small than it is<br>
> to be fast or full of features.<br></blockquote><div><br></div><div>Here is my take on it:<br></div><div>The case of this PR is borderline. If we would write down a hard criterion, this likely would not meet it. Rationale: if we get 100 PRs like this, the average performance of numpy for a user would not change all that much, however we have by then blown up the size NumPy takes up (disk/RAM/download/etc) by a factor 2.4. *However*, we won't get 100 PRs like this. So judging this based on such a criterion isn't quite right. We have this PR now, and it's good to go. Presumably it helps @qwhelan significantly. So I'm +0.5 for merging it.<br></div><div><br></div><div>Also note that Cython has the same problem: taking one function and putting it in a .pyx file gives a huge amount of bloat (example: `scipy.ndimage.label`). We had the same discussion there, but it never became a practical issue because there were not many other PRs like that.<br><br>tl;dr let's merge this, and let's try not to make these kinds of changes a habit</div><div><br></div><div>Cheers,<br></div><div>Ralf<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> This is interesting to us just to judge on how to handle marginal<br>
> improvements which come with relatively large increases in binary size.<br>
> With some use case information we can better estimate were it is<br>
> worthwhile to think about alternatives or to spend more benchmarking<br>
> work to determine the most important cases and where not.<br>
> <br>
> If there are such environments there are other options than blocking or<br>
> complicating future enhancements, like for example add a compile time<br>
> option to make it smaller again by e.g. stripping out hardware specific<br>
> code or avoiding size expensive optimizations.<br>
> But without concrete usecases this appears to be a not something worth<br>
> spending time on.<br>
> <br>
> On 26.04.19 11:47, Éric Depagne wrote:<br>
> > Le vendredi 26 avril 2019, 11:10:56 SAST Ralf Gommers a écrit :<br>
> > Hi Ralf,<br>
> > <br>
> >> Right now a wheel is 16 MB. If we increase that by 10%/50%/100% - are we<br>
> >> causing a real problem for someone?<br>
> > <br>
> > Access to large bandwidth is not universal at all, and in many countries<br>
> > (I'd even say in most of the countries around the world), 16 Mb is a<br>
> > significant amount of data so increasing it is a burden.<br>
> <br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
<br>
<br>
-- <br>
Un clavier azerty en vaut deux<br>
----------------------------------------------------------<br>
Éric Depagne                            <br>
<br>
<br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div></div>