[erlang-questions] specs for fixed length lists

Erik Søe Sørensen eriksoe@REDACTED
Tue Jul 10 11:19:56 CEST 2012


Just read up on it; the dsetel pass doesn't have that kind of magic.
Specifically,
- it can only handle fixed indexes;
- the resulting destructive update doesn't check the tuple size, so the
elements must be updated in a descending-index order;
- there must be no chance of GC kicking in between creation of the tuple
and the destructive update (or else there might be introduced an
old-generation-to-new-generation pointer).
So not only doesn't dsetel at present optimize setelement calls across a
loop, it is not likely to get that ability in the future either.

Apparently dsetel is rather narrowly aimed at optimizing record updates; it
doesn't try to be much cleverer than needed for that job.

2012/7/10 Erik Søe Sørensen <eriksoe@REDACTED>

> It can optimize setelement used in a loop? I'd be surprised, although
> pleasantly so.
> (I didn't even know it could handle non-fixed indexes, but then I am not
> generally very familiar with it.)
> One more thing to research...
> Den 10/07/2012 10.10 skrev "Anthony Ramine" <n.oxyde@REDACTED>:
>
> I wouldn't be so sure about that, you need to check whether the
>> destructive updates pass (dsetel) does its magic here.
>>
>> --
>> Anthony Ramine
>>
>> Le 10 juil. 2012 à 01:50, Erik Søe Sørensen a écrit :
>>
>> > Using setelement is a bad idea, at least unless the tuples are very
>> small: the cost in time and allocation is n^2.
>> > A better scaling approach is to use tuple_to_list + map +
>> list_to_tuple; that should be linear, and my guess is that it'd be faster
>> even for small tuple sizes.
>> > (For the actual n=4 case, I don't know which is better; must
>>  measure...)
>> > /Erik
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120710/77ba7a97/attachment.htm>


More information about the erlang-questions mailing list