[erlang-questions] (Non)Parametrized modules, inheritance, and R15B02 issues?

[Yurii Rashkovskii]

What is even more sad, I've been told that tuple modules will likely be 
killed in the name of performance.


Earlier this year I conducted an experiment and sent its proceedings to 
Björn and this mailing list, but I have never heard back from him.


Here it is again:


"I actually just did a totally unscientific test. I took the maint
branch, and ran 10,000,000 Mod:fn() calls where Mod was passed from
another function call and was just an atom. I ran it on maint, and on
my Mac Pro timer:tc clocked 446983 (that's 0.446 seconds).

After that, I brutally removed tuple call support from apply and
fixed_apply BIFs in beam_emu.c, making `if (is_not_atom(module))` go
straight to error label. I also removed `this` variable which was used
in those checks because there was no need for it anymore.

I re-ran the test, and timer:tc clocked 440680 and around.

So, the runtime cost difference was about 6000 microseconds, or 0.006
seconds, for 10 million calls. If I am not mistaking, this is a 1.35%
speedup on something as low cost as about 0.0446 microseconds per call
(or 0.0440 microseconds per call without support for tuple calls).

Is it this big of a difference to support the removal? What if we made
tuple calls a documented feature? I'd be glad to write an EEP to
support it."

On Friday, October 12, 2012 10:35:26 AM UTC-7, Yurii Rashkovskii wrote:
>
> From what I learned earlier this year, tuple modules have a bleak future 
> as well:
>
> ===
>
> [1] > But I was wondering if there's any word out about the fate of tuple
> > modules? The ones like {erlang}:element(1). Are they expected to be
> > kept around? (I certainly hope they are :)
> >
>
> No, we don't expect to keep them.
>
> As pointed out by others, "tuple modules" is just an implementation
> detail of parameterized modules (which is an experimental feature).
>
> We have not reached a decision yet, but in the future we expect
> we will do one of two things:
>
> * Remove parameterized modules completely from the compiler
> and run-time system.
>
> OR
>
> * Implement parameterized modules properly by creating a new
> data type, both to allow better type checking by Dialyzer, and
> to possibly improve performance.
>
> /Björn
> ====
>
> On Friday, October 12, 2012 1:04:52 AM UTC-7, Gleb Peregud wrote:
>>
>> I believe that someone from OTP team mentioned that the parametrized 
>> modules are to be deleted, but tuple modules will stay. Essentially 
>> this will mean that instead of writing: 
>>
>> -module(person, [FirstName, LastName]). 
>> -compile(export_all). 
>> first_name() -> 
>>   FirstName. 
>>
>> You will have to write: 
>>
>> -module(person). 
>> -record(person, {first_name, last_name}). 
>> -compile(export_all). 
>> new(FirstName, LastName) -> 
>>   #person{first_name = FirstName, last_name = LastName}. 
>> first_name(Person) -> 
>>   Perosn#person.first_name. 
>>
>> but you will still be able to do: 
>>
>>    Person = person:new("Joe", "Armstrong"). 
>>    Person:first_name(). 
>>    "Joe" 
>>    case Person:save() of 
>>        {ok, SavedPerson} -> % do something ... 
>>        {error, ValidationErrors} -> % do something else ... 
>>    end. 
>>
>> So from point of view of readability there will be no change, 
>> althought the amount of code in the model module (person.erl) will 
>> slightly increase. 
>>
>> Please correct me if I am wrong. 
>>
>> Cheers, 
>> Gleb 
>> _______________________________________________ 
>> erlang-questions mailing list 
>> erlang-q...@REDACTED 
>> http://erlang.org/mailman/listinfo/erlang-questions 
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121012/b6532cbc/attachment.htm>