Code Performance

[koorb]

Every so often I read something like:
"use a defensive code technique like File.Exists instead of a Try and
Catch because it's less of a performance hog"

And when I program, I obviously have different ideas on how to code
different sections. So how to I findout what's best from a performance
point-of-view?

[Richard Myers]

Test and read.

Do you understand what they mean by defensive coding techniques in this
scenario?

Richard
"koorb" <ko***@raidrs.c o.uk> wrote in message
news:bu******** *************** *********@4ax.c om...

Every so often I read something like:
"use a defensive code technique like File.Exists instead of a Try and
Catch because it's less of a performance hog"

And when I program, I obviously have different ideas on how to code
different sections. So how to I findout what's best from a performance
point-of-view?

[koorb]

On Sat, 21 Aug 2004 12:40:59 +1200, "Richard Myers"
<ri************ *********@basd. co.nz> wrote:

Test and read.

Do you understand what they mean by defensive coding techniques in this
scenario?

Richard

Yep, but is there a way of finding out the difference in performance
between two sets of the same code?

[Herfried K. Wagner [MVP]]

* koorb <ko***@raidrs.c o.uk> scripsit:

Test and read.

Do you understand what they mean by defensive coding techniques in this
scenario?

Richard

Yep, but is there a way of finding out the difference in performance
between two sets of the same code?

Experience and testing.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Richard Myers]

It depends what performance metric your trying to optimise for? Speed,
memory usage etc.

We're not trying to be smart arsed about it but there are so many different
answers to your question. For example if it were purely speed, you could
test a given method/algorithm by timestamping the entry/exit points for each
alternative implementation. i.e test.

More often though it as important to know why one alternative is
faster/slower than another as this can have implications for other metrics.
For instance if you are optimising purely for speed then you have one
variable to consider, but if you're optimising for speed/memory useage then
you have 2 variables to consider, so then you have to give a relative weight
to each in terms of its performance.

If as above, then you might choose the slower algorithm because you have
afforded memory useage a greater weighting in terms of solution
effectiveness. Hence Herfrieds comments about experience.

Theres no definitive answer to this question...as everything "depends".

[rob willaar]

I often use this code to check performance:

Dim tm As Double

tm = Microsoft.Visua lBasic.Timer

'do something

MsgBox(Microsof t.VisualBasic.T imer - tm)
It's not perfect but better then nothing

"koorb" <ko***@raidrs.c o.uk> schreef in bericht
news:bu******** *************** *********@4ax.c om...

Every so often I read something like:
"use a defensive code technique like File.Exists instead of a Try and
Catch because it's less of a performance hog"

And when I program, I obviously have different ideas on how to code
different sections. So how to I findout what's best from a performance
point-of-view?

[Cor Ligthert]

Koorb,

Performance can seldom be the priority (in a PC application, I am not
talking about PDA).

Most programs on modern computers are much faster than a user can act.

Your example you can test if a File.Exist so why not test on that, you can
than take the proper procedures.

You cannot test if the file is damaged, so you need to use the try as well.

This is not a matter of performance, when you user has a problem, you have a
much larger problem than when the object is deboxed in 1/100000000 of a
nanosecond or that it is deboxed in 1/99999999 of a nanaosecond.

Just my 2 eurocents

Cor

[koorb]

On Sat, 21 Aug 2004 14:20:19 +0200, "Cor Ligthert"
<no**********@p lanet.nl> wrote:

Koorb,

Performance can seldom be the priority (in a PC application, I am not
talking about PDA).

Most programs on modern computers are much faster than a user can act.

Your example you can test if a File.Exist so why not test on that, you can
than take the proper procedures.

You cannot test if the file is damaged, so you need to use the try as well.

This is not a matter of performance, when you user has a problem, you have a
much larger problem than when the object is deboxed in 1/100000000 of a
nanosecond or that it is deboxed in 1/99999999 of a nanaosecond.

Just my 2 eurocents

Cor

Ok thanks, I suppose it's not worth worrying about unless there is an
actual problem then.

[Herfried K. Wagner [MVP]]

* koorb <ko***@raidrs.c o.uk> scripsit:

Ok thanks, I suppose it's not worth worrying about unless there is an
actual problem then.

Make sure your code can be understood easily -- that's much more
important than some milliseconds more of execution time.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[koorb]

On 21 Aug 2004 14:54:02 +0200, hi************* **@gmx.at (Herfried K.
Wagner [MVP]) wrote:

* koorb <ko***@raidrs.c o.uk> scripsit:

Ok thanks, I suppose it's not worth worrying about unless there is an
actual problem then.

Make sure your code can be understood easily -- that's much more
important than some milliseconds more of execution time.

I always get praised for my code being easily understood so there is
no worries there. Plus I comment a lot.