efficiency question - nested function cals

  • Thread starter Thread starter Marc Pelletier
  • Start date Start date
M

Marc Pelletier

Hello,

Are nested function calls inefficient (or inherently evil)? In Delphi
I've seen small but significant performance improvements by always
declaring a local variable and 'unwrapping' the nested calls, but I'm not
convinced it is necessarily so in c#. So for example:

public struct TideValue {
public TideValue( double Time, double Height )
{
time = Time;
height = Height;
}
public double time;
public double height;
}

public class TideClass {
private ArrayList Values;
private double GetTideValue ( double aTime )
{
do something
return something
}
public void CalcTides( double starttime, double endtime )
{
while ( starttime < endtime )
{
Values.Add( new TideValue( curtime, GetInstantHeight( curtime ) )
);
}
}
}

or will this be more efficient;
public void CalcTides( double starttime, double endtime )
{
while ( starttime < endtime )
{
double height = GetInstantHeight( curtime );
TideValue value = new TideValue( curtime, height )
Values.Add( value );
}
}

I'm going to be thousands of these, so small improvements addup. I will,
of course, be doing some tests once the code works, but I'm curious to
know what the rules are for this sort of thing in general.

Thanks

Marc Pelletier
 
Marc Pelletier said:
Are nested function calls inefficient (or inherently evil)? In Delphi
I've seen small but significant performance improvements by always
declaring a local variable and 'unwrapping' the nested calls, but I'm not
convinced it is necessarily so in c#.
Click to expand...

No, I suspect they will be JIT compiled to the same code.
I'm going to be thousands of these, so small improvements addup.
Click to expand...

Possibly - but is it really likely to be your performance bottleneck?

I would personally write the code in the most readable fashion
possible, and only worry about this type of micro-optimisation *if* you
end up with a performance problem - and then certainly only change the
code after making sure that not only does it improve performance, but
that it improves it enough to be worth a loss in readability.
 
No, I suspect they will be JIT compiled to the same code.
Click to expand...

You are right. On 10,000 iterations the execution time is virtually the
same.

But I disagree with your other assertion, that I shouldn't worry about
those issues until I find a bottleneck. I am just learning csharp and this
is surely the time to establish good practices in this language. Good
coding style, once established, can carry you far. For example the
execution time in this case is the same, but the unnested version is much
easier to debug.

I've done a few more optimisation tests that gave very confusing results...
see my other post.

Thanks

Marc Pelletier
 
I've done a few more optimisation tests that gave very confusing
results... see my other post.
Click to expand...

Never mind, I cancelled the other post. It turns out that timing results
vary a great deal when run from the debugger compared to running
standalone. In fact when running from the debugger I was getting very
consistent results showing that order of execution of the tests affected
their timing, by factors of as much as 25%!

cheers

Marc
 
Marc Pelletier said:
You are right. On 10,000 iterations the execution time is virtually the
same.

But I disagree with your other assertion, that I shouldn't worry about
those issues until I find a bottleneck. I am just learning csharp and this
is surely the time to establish good practices in this language. Good
coding style, once established, can carry you far. For example the
execution time in this case is the same, but the unnested version is much
easier to debug.
Click to expand...

So write that more readable code, as I suggested. If one version is
"much easier to debug", use that version until you find some *really
good* reason not to. It would be silly (IMO) to write less readable
code *everywhere* just because there's a very small chance that the
bottleneck in your code is due to one micro-optimisation. It's far more
likely to end up being either something you can't easily control
(bandwidth, another server, etc), an algorithm, or some combination of
the two (one particular way of doing something which eats bandwidth
when there's an alternative available). I can't remember the last time
a micro-optimisation like this was a problem.

(There's a big difference between this and the similar-looking decision
to use a StringBuilder when building up long strings. That's not a
micro-optimisation of syntax which you can reasonably hope the JIT can
compile away; it's a fundamental problem of creating too many objects.
Even that decision is only relevant when you know the number of strings
to append could end up being reasonably large (or more).)

It's important to get *architecture* right early on - that can make a
*huge* difference to performance, and is very hard to fix later on, but
not actual code.
 
Back
Top