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?

[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**********@p lanet.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.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?

[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**********@p lanet.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 "Refactorin g - 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**********@p lanet.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. :)