I've programmed in a range of languages. There are some that I really enjoy coding in, there are some I can put up with and there are some that frustrate and bore me. Having an interest in language design, I got somewhat curious about what it is that makes working with some languages more enjoyable than others.

A couple of questions came to me right away. First, there is probably a lot of personal preference here. What makes a language enjoyable for me to work in may well be what makes it frustrating to someone else, and vice versa. Second, languages are tools. I've said often enough that different languages are suited to different tasks, and you should pick the one that best fits the job at hand. How important a factor is whether one enjoys working in the language when trying to choose whether to use it in a project or not?

=== Personal Preference ===...

Recently, a friend mentioned that someone had told him that writing a try...catch block in C# (or substitute some other .Net language here) resulted in a "huge penalty" in terms of performance compared to if you had not written it. That is, merely writing such a block actually hurt program performance, even if an exception was never thrown. He didn't believe this was true, and rightly so - it's completely wrong. This post is a tidied up version of my explanation.

Inside a .Net Assembly

A .Net assembly, if we ignore various headers, consists of three things:

• Bytecode: a sequence of low-level instructions that specify the body of a method
• Metadata: a set of tables, a little bit like a database, describing higher level constructs such as classes, methods, signatures and so forth
• Heaps: places where string constants and other such things are stored...

Sometimes a program you have written just doesn't run fast enough. In this article I'm going to look at how (and how not) to approach such problems along with some tips for speeding things up in various cases.

Stop Right There!

The biggest mistake people make when trying to improve the performance of their programs is jumping straight in and trying to do it without first understanding where the bottleneck lies. Often the real performance issue may not lie where you think it does.

Tools for analyzing program performance are called profilers. They will tell you which functions and sometimes even which lines of the program are taking up what factor of the execution time. This is highly valuable information and can save you a lot of wasted time. Without it, you might set about optimizing a function or method that is only taking a tiny fraction of the execution time anyway...

Most programmers today will be familiar with a number of programming paradigms. The age-old procedural programming paradigm, where a program is broken down into a number of procedures or routines, is still very much alive and the right solution for a number of problems. Object Oriented programming is one of the most popular and fashionable paradigms today, allowing for a good level of code re-use through mechanisms such as instance management (one class can be instantiated many times to give many objects), data hiding (think private variables in a class) and inheritance.

Another paradigm cross-cuts these two: that of imperative programming. This simply means that a program consists of a sequence of instructions that are executed one after the other (or at least appear to be; both the compiler and the CPU may well re-order instructions to improve performance when it does not affect the behavior of the program). In fact, when I was younger my definition of a computer program included the words “a sequence of instructions”...