I believe it is also worth mentioning that according to Joe Armstrong "the abuse of param modules are here to stay" and should be documented:<div><br></div><div><a href="https://groups.google.com/group/erlang-programming/browse_thread/thread/c59e72387167a834/82441aed16f8a7ba?show_docid=82441aed16f8a7ba&pli=1">https://groups.google.com/group/erlang-programming/browse_thread/thread/c59e72387167a834/82441aed16f8a7ba?show_docid=82441aed16f8a7ba&pli=1</a></div>

<div><div><br></div><div>Cheers,</div><div><br></div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b><span style="border-collapse:separate;font-family:arial;font-weight:normal"><div>
<span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div>

<div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Lead Developer</span></div></span></div></span></b></span>
<br><br><div class="gmail_quote">On Sun, Jun 10, 2012 at 9:00 PM, Yurii Rashkovskii <span dir="ltr"><<a href="mailto:yrashk@gmail.com" target="_blank">yrashk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I also got a piece of advise to calculate the cost of running an empty<br>
cycle on both versions of the runtime. It was about 70,000<br>
microseconds on both. This means that while the speedup remains the<br>
same, the cost of actual operations has to be dropped even lower, to<br>
about 0.0370 microseconds per call (on that hardware)<br>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Jun 10, 2012 at 11:48 AM, Yurii Rashkovskii <<a href="mailto:yrashk@gmail.com">yrashk@gmail.com</a>> wrote:<br>
> Björn,<br>
><br>
> I actually just did a totally unscientific test. I took the maint<br>
> branch, and ran 10,000,000 Mod:fn() calls where Mod was passed from<br>
> another function call and was just an atom. I ran it on maint, and on<br>
> my Mac Pro timer:tc clocked 446983 (that's 0.446 seconds).<br>
><br>
> After that, I brutally removed tuple call support from apply and<br>
> fixed_apply BIFs in beam_emu.c, making `if (is_not_atom(module))` go<br>
> straight to error label. I also removed `this` variable which was used<br>
> in those checks because there was no need for it anymore.<br>
><br>
> I re-ran the test, and timer:tc clocked 440680 and around.<br>
><br>
> So, the runtime cost difference was about 6000 microseconds, or 0.006<br>
> seconds, for 10 million calls. If I am not mistaking, this is a 1.35%<br>
> speedup on something as low cost as about 0.0446 microseconds per call<br>
> (or 0.0440 microseconds per call without support for tuple calls).<br>
><br>
> Is it this big of a difference to support the removal? What if we made<br>
> tuple calls a documented feature? I'd be glad to write an EEP to<br>
> support it.<br>
><br>
> You can find my test patch attached.<br>
><br>
> P.S. I also ran the same test for a tuple call (in the maint branch),<br>
> timer:tc clocked 545656 and around. So there is a penalty for using<br>
> tuple calls, but that's expectable and seems to be a reasonable<br>
> tradeoff for me.<br>
> P.P.S. Please let me know if something in this test is incorrect, I'd<br>
> be glad to improve it.<br>
><br>
><br>
> On Sun, Jun 10, 2012 at 10:52 AM, Yurii Rashkovskii <<a href="mailto:yrashk@gmail.com">yrashk@gmail.com</a>> wrote:<br>
>> Björn,<br>
>><br>
>> I wanted to follow up on this. I am investigating this whiole issue<br>
>> (as I really would love to keep tuple calls) and I would like to know<br>
>> whether you have any numbers on how significant the speed impediment<br>
>> of this feature is (the run-time cost incurred in apply/3) that you<br>
>> mentioned earlier? Do you have any comparisons?<br>
>><br>
>> Yurii<br>
>><br>
>> On Mon, Jan 23, 2012 at 11:22 PM, Björn Gustavsson<br>
>> <<a href="mailto:bgustavsson@gmail.com">bgustavsson@gmail.com</a>> wrote:<br>
>>> 2012/1/24 Yurii Rashkovskii <<a href="mailto:yrashk@gmail.com">yrashk@gmail.com</a>>:<br>
>>>> Björn,<br>
>>>><br>
>>>> Is there any way tuple module calls can be separated from parametrized<br>
>>>> modules and subsequently documented and become part of standard<br>
>>>> Erlang?<br>
>>>><br>
>>><br>
>>> Perhaps.<br>
>>><br>
>>> The problem with the current implementation of "tuple modules"<br>
>>> is that the M in apply(M, F, A) and M:F(...) has a strange type, i.e. M can<br>
>>> be either an atom or a tuple. Unless we implement parameterized modules,<br>
>>> we want M to be only an atom. (There is a run-time cost in the<br>
>>> implementation of apply/3 to allow parameterized modules/"tuple modules",<br>
>>> and parameterized modules prevented an optimization I wanted to do in the<br>
>>> compiler for R15B.)<br>
>>><br>
>>> We might consider an alternative implementation of "tuple modules"<br>
>>> that does not use apply(M, F, A) or M:F(...), using either new BIFs or new<br>
>>> syntax. (Example: tuple_module_apply(M, F, A) could behave as apply/3<br>
>>> currently behaves, or alternatively only allow M to be a tuple. This is not<br>
>>> a serious suggestion, just an example to make it clear what I mean.)<br>
>>><br>
>>> I suggest that you write an EEP.<br>
>>><br>
>>> --<br>
>>> Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>