[erlang-questions] The is_record() guard

[Oscar Hellström]

Hi Steve,

You could also do it this way:

transform(#rec_a{} = R) -> ... ;
transform(#rec_b{} = R) -> ... ;
...

IIRC there will indeed be a performance hit when using guards instead of
pattern matchings in the function head. Not sure if this is still the
case, or if my benchmarks were sufficient though. The situation then was
something like:
normalize(Char) when Char < 10 -> ...
normalize(Char) when Char > 13, Char < ... -> ...

Putting the values explicitly in the function head gave more code, but
better performance. Not that it mattered in the end though but useless
optimizations are very common...

Steve Davis wrote:
> I have an application that uses records extensively. At one point in
> processing these records I have a match function:
>
> transform(R) when is_record(R, rec_a) -> ... ;
> transform(R) when is_record(R, rec_b) -> ... ;
> transform(R) when is_record(R, rec_c) -> ... ;
> ...
>
> A first run of fprof appears to show that this function match is
> bottlenecking (noticeably so, but not in dire fashion).
>
> I'm planning a comparative run using transform(element(1, R), R) as
> the call signature:
>
> transform(rec_a, R) -> ...;
> transform(rec_b, R) -> ...;
> transform(rec_c, R) -> ...;
> ....
>
> However - before I refactor, does anybody happen to know whether this
> performance hit would this be expected?
>
> Is the is_record guard known to be slow/heavy in some way?
>
> Regards,
> /sd
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>   


-- 
Oscar Hellström, oscar@REDACTED
Office: +44 20 7655 0337
Mobile: +44 798 45 44 773
Erlang Training and Consulting Ltd
http://www.erlang-consulting.com/