Performance – Using Try/Catch

I just wrote the stupidest program ever.  It is inefficient by design.  If anyone did this thinking “hey… this is great code” they should be fired.

Anyway… generally speaking, using try/catch blocks is not a great idea.  There are a myriad of reasons but it’s usually something along the lines of:

If you truly have an unexpected error it’s better to let the program crash and then fix the bug.

If you do have to use the try/catch exception handling block, you should only catch explicit exceptions.  For example catch a file access exception or a database invalid primary key exception.  Just catching the generic exception is poor practice.

There’s another reason to avoid try/catch though… it is a performance hog.

Read more

Performance – Inline SQL vs Parameterized Queries

In the search for better and better performance, there are many techniques developers can use.  A technique used early on by some entry level or “still learning” developers is to build inline SQL.  That looks something like this:

string name = "Mark";
string query = "SELECT * FROM users WHERE FirstName='" + name + "'";
OleDbCommand cmd = new OleDbCommand(query);
OleDbDataReader reader = cmd.ExecuteReader();

There are steps missing… this is just example code


This is something more seasoned developers learn to avoid almost immediately.  There’s a variety of reasons why inline SQL is bad.  The most important reason is security.

However, there’s another reason to avoid it.  Performance.

Read more

Safari 4 = WOW

I am and have been a Mac head for almost two years. I’m really really happy with their products. Today, they just launched the first beta version of Safari 4. In addition to lot of neat new eye candy, the javascript engine has also been reworked.

All I can say is WOW.
I’m a DotNet programmer by trade. ASPX pages are heavy users of javascript so when I heard that the JS engine was faster, I was really excited to try it out. Sure enough, it’s true. My ASPX pages are significantly faster! If you’re in the mood for an adventure, give Safari 4 a try.

Log4Net and Performance

Wow… I just removed log4net from my project.  What a performance hog log4net is!

Let’s be clear… I had simply disabled log4net by turning the responders “OFF”.  I never modified the code to check to see if debugging was enabled or anything like that.  Just turning it “OFF” didn’t really help anything.  I kept finding errors in the log that it was unable to get access to the log file like it wanted.
By commenting everything out, my performance jumped!  I suppose at some point I’ll go back and add the logic to only log things if it’s turned on.  Right now, I don’t need the logging so I’ll leave it disabled.
Scroll To Top