[DUG] In [set] efficiency

Thu Jun 9 09:43:30 NZST 2016

There's two "optimizations" in play... code efficiency and code
clarity/redundancy/duplication.

   if RadioButton.ItemIndex in [3, 5] then

vs

   if (RadioButton.ItemIndex = 3) or (RadioButton.ItemIndex = 5) then

The former may be more performant but the more significant factor in play
for me here is that it is the clearer and less error prone of the two.

In cases other than this simple radio button item index, the inefficiency
of the latter approach may be even greater than simply the difference
between an "in" and two "or'd" expressions, e.g. if the LHS of the
condition involved some expensive operation to calculate, since it has to
be calculated multiple times.  The duplication and redundancy inherent in
the or's involves repeating these evaluations (unless the compiler is being
especially clever with it's optimisations) which you can of course take
steps to ensure are avoided by introducing a local variable:

   var
     iButtonIndex: Integer;

   iButtonIndex := RadioButton.ItemIndex;
   if (iButtonIndex = 3) or (iButtonIndex = 5) then

But this is a massive step backwards imho.

+0.02

On 9 June 2016 at 08:38, Leigh Wanstead <leigh.wanstead at gmail.com> wrote:

> I agree with Dennis.
>
> Unless your profiler point this set code got so many percentage spent on,
> I will not look at the code to make it faster. If you really want to make
> code faster, there is cuda if you want to take advantage of your nvidia
> graphics card or simd for your cpu :-) There is not much waste in delphi
> convert to assembly or write directly in assembly code to get it faster I
> guess.
>
> Regards
> Leigh
>
> On 9 June 2016 at 07:56, Dennis Chuah <dennis_cs_chuah at hotmail.com> wrote:
>
>>
>> Personally, I wouldn't bother optimising my code at this level. You might
>> save a few micro seconds, but consider the bigger picture. There are lots
>> of
>> other things your program can do that are potentially more time and
>> resource
>> consuming, eg. db access, disk access, network access, algorithms.
>>
>> Run a profiler and find out where your program is inefficient. Consider
>> using worker threads to run lengthy operations.
>>
>> As for the answer to your original question of which is more efficient ...
>> should you really care? Perhaps what is more important is code
>> readability.
>> IMHO, something like
>>
>> a in [1..3, 5]
>>
>> is more readable (and fewer keys to type) than
>>
>> ((a >= 3) and (a <= 5)) or (a = 5)
>>
>> BUT
>>
>> type
>>   TSomeKind = (
>>     skSomeKind = 1,
>>     skAnotherKind = 2,
>>     skYetAnotherKind = 3,
>>     skYouGuessedIt = 4,
>>     skFinally = 5
>>     );
>>
>> a in [skSomeKind, skAnotherKind, skYetanotherKind, skFinally]
>>
>> perhaps better conveys the meaning of the code, assuming the integers 1..5
>> have special meaning in your program.
>>
>> Then, if you only had those enumerations to care about, your condition
>> reduces to
>>
>> a <> skYouGuessedIt
>>
>> which is much more readable, and I am sure more efficient than the other
>> constructs above, if efficiency at this level is that important to you.
>>
>> Regards,
>> Dennis.
>>
>> From: Ross Levis
>> Sent: Thursday, June 9, 2016 12:00 AM
>> To: 'NZ Borland Developers Group - Delphi List'
>> Subject: Re: [DUG] In [set] efficiency
>>
>>
>> So it’s best to reduce the set size as much as possible.  Looking at my
>> code, I have some variables declared as Word (16-bit) with 65535 possible
>> values but most are Byte.
>>
>>
>>
>>
>>
>> From: delphi-bounces at listserver.123.net.nz
>> [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Peter Ingham
>> Sent: Wednesday, 8 June 2016 8:15 p.m.
>> To: delphi at listserver.123.net.nz
>> Subject: Re: [DUG] In [set] efficiency
>>
>>
>>
>>
>>
>>
>>
>> (From memory & without firing up a compiler to verify) ...
>>
>> Sets are implemented as bitmaps with one bit allocated to each possible
>> value of the set type (hence the limitations on the number of possible
>> elements in the set).
>>
>> So if you have
>> type bytesset = [0..7];  // 8 possible values
>> var  a: bytesset ;
>> begin
>>   if a in [1,4] then
>>
>> The set literal [1,4] ends up as a byte with the value $0A.
>> The test "a in [1,4]" is equivalent to "(a AND $0A) <> 0".
>>
>> The generated code (for a set of this size) is an AND  followed by a
>> conditional jump.  Very efficient.
>>
>> It gets a little nastier when the possible values gets larger as the size
>> of
>> the set grows  (set of AnsiChar is 32 bytes; Set of Widechar exceeds the
>> permissible size of a set).
>>
>> The precise code generated by case varies between jump tables and linear
>> comparisons.
>>
>> Regards
>>
>>
>> On 8/06/2016 5:27 p.m., 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 listPost: delphi at listserver.123.net.nzAdmin:
>> http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: 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
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20160609/e6df5beb/attachment-0001.html 