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.co.uk> wrote in message
news:bu********************************@4ax.com...

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.co.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.VisualBasic.Timer

'do something

MsgBox(Microsoft.VisualBasic.Timer - tm)
It's not perfect but better then nothing

"koorb" <ko***@raidrs.co.uk> schreef in bericht
news:bu********************************@4ax.com...

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**********@planet.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.co.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.co.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.

[Cor Ligthert]

> I always get praised for my code being easily understood so there is

no worries there. Plus I comment a lot.

When your code is easily to understood there is no need for commenting.

I could not resist in this.

:-)

Cor

[Herfried K. Wagner [MVP]]

* "Cor Ligthert" <no**********@planet.nl> scripsit:

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

When your code is easily to understood there is no need for commenting.

Aren't comments /part of/ the code?

:-)

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

[Jay B. Harlow [MVP - Outlook]]

Koorb,
In addition to the other statements.

Remember the 80/20 rule! That is 80% of the execution time of your program
is spent in 20% of your code. I will optimize (worry about performance) the
20% once that 20% has been identified & proven to be a performance problem
via profiling (CLR Profiler is one profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

In the File.Exists case, it really depends on whether you should use it or
not. On both the likely hood of the file existing & how often you are
creating the file.

For example, if I am coding the "File Save" command for a Windows Forms
Application, then I probably would not worry about coding for File.Exists.

However! if I am coding a file save routine for a Window Service application
that is processing 100s of files per minute, then I would use the File.Exits
to avoid the overhead of possible 100s of exceptions per minute.

CLR Profiler is a tool you can reliably use to see if you app is not
releasing memory as it should.

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

In addition to the above articles, The following articles provide
information on writing .NET code that performs well. I believe one of the
covers how to use Performance Monitor under Control Panel to monitor the
memory usage of your app.

http://msdn.microsoft.com/architectu...l/scalenet.asp

http://msdn.microsoft.com/library/de...anagedcode.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

http://msdn.microsoft.com/library/de...vbnstrcatn.asp

http://msdn.microsoft.com/library/de...tchperfopt.asp

http://msdn.microsoft.com/library/de...tperftechs.asp
Hope this helps
Jay
"koorb" <ko***@raidrs.co.uk> wrote in message
news:bu********************************@4ax.com...

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]

When your code is easily to understood there is no need for commenting.

Whats really annoying is when you can understand another developers code but
not their comments.
Sometimes less is more.

;)

[Herfried K. Wagner [MVP]]

* "Richard Myers" <ri*********************@basd.co.nz> scripsit:

When your code is easily to understood there is no need for commenting.

Whats really annoying is when you can understand another developers code but
not their comments.
Sometimes less is more.

I always try to keep my code self-explaining, without the use
of comments. Sometimes that's impossible, but often comments are used
to compensate poor/bad style.

;-)

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

[Cor Ligthert]

Herfried,

I always try to keep my code self-explaining, without the use
of comments. Sometimes that's impossible, but often comments are used
to compensate poor/bad style.

;-)

Aha, so why this sentence from you in this thread before on a sentence with
the same meaning as above?

Aren't comments /part of/ the code?

:-)

Cor

[Herfried K. Wagner [MVP]]

Cor,

* "Cor Ligthert" <no**********@planet.nl> scripsit:

I always try to keep my code self-explaining, without the use
of comments. Sometimes that's impossible, but often comments are used
to compensate poor/bad style.

;-)

Aha, so why this sentence from you in this thread before on a sentence with
the same meaning as above?

Aren't comments /part of/ the code?

Comments are a part of the code that should be used only if it's really
necessary ;-).

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

[Jay B. Harlow [MVP - Outlook]]

Herfried,
If you read "Refactoring - Improving the design of Existing Code" by Martin
Fowler from Addison Wesley http://www.refactoring.com/

Martin would suggests that too many comments is a "bad smell" in your code.
A "bad smell" is a section of cod that needs to be improved. Specifically
Martin states in reference to a long methods:

"A heuristic we follow is that whenever we feel
the need to comment something, we write a method
instead. Such a method contains the code that was
commented but is named after the intention of the
code rather then how it does it".

Basically if you have a long method where you have a comment every 10 or 15
lines, that each of those 10 or 15 lines should be its own method, where the
name of the method is the comment.

Martin is not suggesting you do not put comments before methods that explain
what the method does, what it expects & what it returns. He is referring to
comments within the method bodies themselves.

Hope this helps
Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2o************@uni-berlin.de...

* "Cor Ligthert" <no**********@planet.nl> scripsit:

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

When your code is easily to understood there is no need for commenting.

Aren't comments /part of/ the code?

:-)

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

[koorb]

On Sat, 21 Aug 2004 18:56:16 -0500, "Jay B. Harlow [MVP - Outlook]"
<Ja************@msn.com> wrote:

Koorb,
In addition to the other statements.

Remember the 80/20 rule! That is 80% of the execution time of your program
is spent in 20% of your code. I will optimize (worry about performance) the
20% once that 20% has been identified & proven to be a performance problem
via profiling (CLR Profiler is one profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

<snip>

Some interesting philosophical reading, but with the small stuff I am
writing at the moment the best thing is simply, be responsible with
variables and to make each event quick and painless.

Although I think that profiler might come in handy. :)