[DUG] In [set] efficiency

[Jolyon Direnko-Smith]

Rohit, I'm not sure when you think this change occurred but as far as I can
recall (and I've just tested that memory with Delphi 7) it has never been
possible to have duplicate case labels. If it were, I'm pretty sure it
would have been considered a bug and would have been fixed as such.

My C is too rusty to recall whether C formally allows duplicate case
labels, but I seem to recall that even if not possible then it is possible
to simulate same/similar effects by injudicious use (or omission) of
break's within the switch but that this is generally frowned upon.


To answer the original question, a simple test case and use of the
disassembly view confirms that the compiler produces different code for
each variant.  The code in each case performs a simple test of integer *a*
and simply shows a message if the test evaluates as true:

*Unit12.pas.35: if a in [1, 3] then*
005B166C A164535C00       mov eax,[$005c5364]
005B1671 83E801           sub eax,$01
005B1674 7405             jz $005b167b
005B1676 83E802           sub eax,$02
005B1679 750A             jnz $005b1685
*Unit12.pas.36: ShowMessage('in');*
005B167B B898165B00       mov eax,$005b1698
005B1680 E8A34AF9FF       call ShowMessage


*Unit12.pas.41: if (a = 1) or (a = 3) then*
005B16AC 833D64535C0001   cmp dword ptr [$005c5364],$01
005B16B3 7409             jz $005b16be
005B16B5 833D64535C0003   cmp dword ptr [$005c5364],$03
005B16BC 750A             jnz $005b16c8
*Unit12.pas.42: ShowMessage('() or ()');*
005B16BE B8D8165B00       mov eax,$005b16d8
005B16C3 E8604AF9FF       call ShowMessage


How this scales w.r.t many more items in the set membership being tested I
don't know, but you can see from this that the OR'd value comparisons is
compiled as multiple comparisons where-as the set membership test produces
very different ASM.

I don't know x86 ASM well enough to say which of these is more efficient
but the simple fact that they are different suggests that there is likely
to be a difference in performance (and I suspect that multiple CMP's are
likely to be more costly than whatever contrivance is involved in the set
membership test).

NOTE: This is the dis-assembly of Delphi XE4 Win32 code.  Code produced for
other targets may (almost certainly will) vary.



On 28 July 2016 at 14:52, Rohit Gupta <rohit at cfl.co.nz> wrote:

> Steve,
>
> I am pretty sure you are correct.  This happened when they scrapped the
> pascal compiler and changed the c compiler to do pascal.  One of the
> changes then was that you could not use the same selector value twice in
> the case statement.  Before that time, you could.
>
> Rohit
>
>
> On 8/06/2016 17:27, Steve Peacocke wrote:
>
> If I remember correctly, the compiler changes both to array anyway so you
> come out with exactly the same compiled code.
>
> Perhaps someone can confirm this or tell me how wrong I am?
>
> Steve Peacocke
> +64 220 612-611
>
>
> On 8/06/2016, at 4:56 PM, Ross Levis <ross at stationplaylist.com> wrote:
>
> I’m wondering which is more efficient to process...
>
>
>
> if (a=1) or (a=2) then ...
>
>
>
> or
>
>
>
> if a in [1,2] then ...
>
>
>
> If the answer is the first method, does it make a difference if more
> numbers are checked, eg. if a in [1..3,5] then
>
>
>
> Cheers.
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe
>
>
> --
>
> Regards
>
> *Rohit Gupta*
> B.E. Elec., M.E., Mem IEEE, Mem IET
> Technical Director
> Computer Fanatics Ltd
>
> *Tel *4892280
> *Fax *4892290
> *Web *www.cfl.co.nz
> ------------------------------
> This email and any attachments contain information, which is confidential
> and may be subject to legal privilege and copyright. If you are not the
> intended recipient, you must not use, distribute or copy this email or
> attachments. If you have received this in error, please notify us
> immediately by return email and then delete this email and any attachments.
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at listserver.123.net.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20160728/c382c8ed/attachment.html