<div dir="auto">That's why I suggested to add new benchmark.</div><br><div class="gmail_quote"><div dir="ltr">2018年6月19日(火) 22:22 Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com">levkivskyi@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 19 June 2018 at 13:02, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank" rel="noreferrer">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 19 June 2018 at 16:12, INADA Naoki <<a href="mailto:songofacandy@gmail.com" target="_blank" rel="noreferrer">songofacandy@gmail.com</a>> wrote:<br>
><br>
> On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <<a href="mailto:J.Demeyer@ugent.be" target="_blank" rel="noreferrer">J.Demeyer@ugent.be</a>> wrote:<br>
>><br>
>> On 2018-06-18 16:55, INADA Naoki wrote:<br>
>> > Speeding up most python function and some bultin functions was very<br>
>> > significant.<br>
>> > But I doubt making some 3rd party call 20% faster can make real<br>
>> > applications significant faster.<br>
>><br>
>> These two sentences are almost contradictory. I find it strange to claim<br>
>> that a given optimization was "very significant" in specific cases while<br>
>> saying that the same optimization won't matter in other cases.<br>
><br>
><br>
> It's not contradictory because there is basis:<br>
><br>
>   In most real world Python application, number of calling Python methods or<br>
>   bulitin functions are much more than other calls.<br>
><br>
> For example, optimization for bulitin `tp_init` or `tp_new` by FASTCALL was<br>
> rejected because it's implementation is complex and it's performance gain is<br>
> not significant enough on macro benchmarks.<br>
><br>
> And I doubt number of 3rd party calls are much more than calling builtin<br>
> tp_init or tp_new.<br>
<br>
</span>I don't think this assumption is correct, as scientific Python<br>
software spends a lot of time calling other components in the<br>
scientific Python stack, and bypassing the core language runtime<br>
entirely.<br><div class="m_4366445013357374346HOEnZb"><div class="m_4366445013357374346h5"><br></div></div></blockquote><div><br></div><div>A recent Python survey by PSF/JetBrains shows that almost half of current Python</div><div>users are using it for data science/ML/etc. For all these people most of the time is spent</div><div>on calling C functions in extensions.</div><div><br></div><div>--</div><div>Ivan </div></div><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div>