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?

Test and read.

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

Richard


"koorb" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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?

On Sat, 21 Aug 2004 12:40:59 +1200, "Richard Myers"
<richard.spam-(E-Mail Removed)> 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?

* koorb <(E-Mail Removed)> 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/>

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".

I often use this code to check performance:

Dim tm As Double

tm = Microsoft.VisualBasic.Timer

'do something

MsgBox(Microsoft.VisualBasic.Timer - tm)


It's not perfect but better then nothing

"koorb" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> 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,

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

On Sat, 21 Aug 2004 14:20:19 +0200, "Cor Ligthert"
<(E-Mail Removed)> 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.

* koorb <(E-Mail Removed)> 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/>

On 21 Aug 2004 14:54:02 +0200, hirf-spam-me-(E-Mail Removed) (Herfried K.
Wagner [MVP]) wrote:

>* koorb <(E-Mail Removed)> 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.