case execution time

[Cristian Tots]

Hi,

I have a large 'case' block (around 60 values to test). I was wondering how
much impact the comparison time would have on performance. Could this
penalty be ignored?

Cristian

[Artie Gold]

Re: case execution time

Cristian Tots wrote:[color=blue]
> Hi,
>
> I have a large 'case' block (around 60 values to test). I was wondering how
> much impact the comparison time would have on performance. Could this
> penalty be ignored?
>[/color]
Impossible to say, as it's a quality-of-implementation issue -- or
perhaps not even that.

As always with optimization questions, if things are not running
quickly enough, profile -- and once you're sure that something is a
bottleneck, look into other options.

HTH,
--ag

--
Artie Gold -- Austin, Texas
Oh, for the good old days of regular old SPAM.

[EventHelix.com]

Re: case execution time

The overhead of a case statement depends upon the compiler and
the relative closeness of the different case values. If the values
are very close, the compiler might generate a case variable indexed
jump table.

Some compilers perform a binary search when the number of entries is
this large.

Checkout the following article for more details.

http://www.eventhelix.com/RealtimeMantra/Basics/OptimizingCAndCPPCode.htm

For the inner workings of a case statement are covered in the
following article:

http://www.eventhelix.com/RealtimeMantra/Basics/CToAssemblyTranslation3.htm

Sandeep
--

http://www.EventHelix.com/EventStudio

EventStudio 2.0 - Generate Sequence Diagrams and Use Case Diagrams in PDF

[Rolf Magnus]

Re: case execution time

Cristian Tots wrote:
[color=blue]
> Hi,
>
> I have a large 'case' block (around 60 values to test). I was
> wondering how much impact the comparison time would have on
> performance. Could this penalty be ignored?[/color]

That depends on the compiler and maybe on the values you test, but
often, there is no comparison and switch/case is _very_ fast.

[Cristian Tota]

Re: case execution time

Thanks,

I guess it's better to use an array of function pointers instead. I haven't
implemented it yet but it would get rid of the switch.

Cristian

"Rolf Magnus" <ramagnus@t-online.de> wrote in message
news:boqjcm$t22 $04$2@news.t-online.com...[color=blue]
> Cristian Tots wrote:
>[color=green]
> > Hi,
> >
> > I have a large 'case' block (around 60 values to test). I was
> > wondering how much impact the comparison time would have on
> > performance. Could this penalty be ignored?[/color]
>
> That depends on the compiler and maybe on the values you test, but
> often, there is no comparison and switch/case is _very_ fast.
>[/color]

[tom_usenet]

Re: case execution time

On Tue, 11 Nov 2003 16:29:00 +0200, "Cristian Tota"
<cristian.tota@ vion-software.ro> wrote:
[color=blue]
>Thanks,
>
>I guess it's better to use an array of function pointers instead. I haven't
>implemented it yet but it would get rid of the switch.[/color]

However, the performance benefit from the code for each case being
inlined might outweight the benefit you get in just doing an array
dereference. Calling through a function pointer disables inlining
(usually).

Tom

[Rolf Magnus]

Re: case execution time

Cristian Tota wrote:
[color=blue]
> Thanks,
>
> I guess it's better to use an array of function pointers instead. I
> haven't implemented it yet but it would get rid of the switch.[/color]

As I wrote, depending on the compiler and the values, switch/case may be
very fast, and its complexity can be O(1), i.e. not dependant on the
number of cases you have. Many people think of switch/case as just
another way to write an if/else if cascade, but in fact, compilers may
(and often do) choose to implement it as a jump table with the
to-be-tested value as index into that table, which makes it faster than
any other alternative.

[lilburne]

Re: case execution time

tom_usenet wrote:[color=blue]
> On Tue, 11 Nov 2003 16:29:00 +0200, "Cristian Tota"
> <cristian.tota@ vion-software.ro> wrote:
>
>[color=green]
>>Thanks,
>>
>>I guess it's better to use an array of function pointers instead. I haven't
>>implemented it yet but it would get rid of the switch.[/color]
>
>
> However, the performance benefit from the code for each case being
> inlined might outweight the benefit you get in just doing an array
> dereference. Calling through a function pointer disables inlining
> (usually).
>[/color]

Just to emphasis the point.

Once upon a time (back in 1982), I profiled some C code
compiled on an 16 bit computer and found that 40% of the
time was spent converting 16 bit ints to 32 bit ints doing
pointer arithmetic. Using that particular compiler
microlevel optimizations were a complete waste of time.

Microlevel optimization ought to be the last thing you do,
after you have profiled your code and really discovered
where the bottlenecks are. As others have said these
optimizations may gain you a few percentage points in
performance. Smarter algorithms and data structures, on the
other hand can gain you orders of magnitude better performance.